Opened 8 years ago

Closed 8 years ago

#3215 closed enhancement (implemented)

RFC: Plugin framework design

Reported by: chiiph Owned by: chiiph
Priority: Medium Milestone: Vidalia: 0.3.x
Component: Archived/Vidalia Version:
Severity: Keywords:
Cc: edmanm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Here's a first draft of the plugin framework design:

https://gitweb.torproject.org/chiiph/vidalia.git/blob/ade1882477472b871975e70d18dce87cf911eb55:/doc/plugin-framework.txt

The development will take place at my branch chiiph/plugin.

I thought about documenting examples for each of the parts that need to be developed, but I think it's better to have them when we know code like that is working properly with the design I'm proposing.

Thoughts?

Child Tickets

Change History (7)

comment:1 Changed 8 years ago by nickm

Two things I wondered skimming it just now:

What API do plugins get to use? Which functions do they get to call?

Do you have links to a few examples of plugins you think ought to exist? For design things like this, I like to sketch out some example clients as I do it to make sure that I'm not "generalizing from zero samples".

comment:2 in reply to:  1 ; Changed 8 years ago by chiiph

Replying to nickm:

Two things I wondered skimming it just now:

What API do plugins get to use? Which functions do they get to call?

They get to use whatever we give them to use. The basics would be: VidaliaSettings, TorControl and other Tor abstractions (Circuit, Stream, etc), and everything (or almost) needed for building a fully functional GUI, along with some other class like QProcess.
For each class that we want to be available inside the plugin, you need to set up an interface as described in the doc, and load it to the script engine.

Do you have links to a few examples of plugins you think ought to exist? For design things like this, I like to sketch out some example clients as I do it to make sure that I'm not "generalizing from zero samples".

Sure, I have example code, but not actual examples that follow the rules specified. Since you need to provide everything that can be used in the plugin, I have some toy examples, but nothing that seems close to a future plugin for Vidalia.
The first plugin that I'll build would be the one that starts Firefox for TBB.
I could code the plugin before being able to run it (may be this was what you meant?).

comment:3 in reply to:  2 ; Changed 8 years ago by nickm

Replying to chiiph:

Replying to nickm:

Two things I wondered skimming it just now:

What API do plugins get to use? Which functions do they get to call?

They get to use whatever we give them to use. The basics would be: VidaliaSettings, TorControl and other Tor abstractions (Circuit, Stream, etc), and everything (or almost) needed for building a fully functional GUI, along with some other class like QProcess.
For each class that we want to be available inside the plugin, you need to set up an interface as described in the doc, and load it to the script engine.

Okay. You should probably make a list, or start tagging stuff in the code, or something. Once there is a plugin format, these interfaces will need to not change, or else plugins will break, so they'll need to be part of the documented API of "What Plugins Can Call."

Do you have links to a few examples of plugins you think ought to exist? For design things like this, I like to sketch out some example clients as I do it to make sure that I'm not "generalizing from zero samples".

Sure, I have example code, but not actual examples that follow the rules specified. Since you need to provide everything that can be used in the plugin, I have some toy examples, but nothing that seems close to a future plugin for Vidalia.
The first plugin that I'll build would be the one that starts Firefox for TBB.
I could code the plugin before being able to run it (may be this was what you meant?).

I'm mainly hoping that you've thought of more than just one or two things to do as plugins, and that you've thought through them in enough detail to be sure that your framework will handle them, and that there aren't any parts of the framework that aren't there because of some actual requirement.

comment:4 in reply to:  3 Changed 8 years ago by chiiph

Replying to nickm:

Replying to chiiph:

Replying to nickm:

Two things I wondered skimming it just now:

What API do plugins get to use? Which functions do they get to call?

They get to use whatever we give them to use. The basics would be: VidaliaSettings, TorControl and other Tor abstractions (Circuit, Stream, etc), and everything (or almost) needed for building a fully functional GUI, along with some other class like QProcess.
For each class that we want to be available inside the plugin, you need to set up an interface as described in the doc, and load it to the script engine.

Okay. You should probably make a list, or start tagging stuff in the code, or something. Once there is a plugin format, these interfaces will need to not change, or else plugins will break, so they'll need to be part of the documented API of "What Plugins Can Call."

Well, this part of the design wasn't aiming to provide an entire API. The idea is that plugins will be able to do whatever you can do by editing the C++ code (just a little bit simpler, since it's javascript basically). You will be able to manipulate widgets just like you do with C++ Qt (but without pointers, and other low level stuff that isn't "available"). You will be able to use the TorControl classes that are available in Vidalia (which is the most important part).

Do you have links to a few examples of plugins you think ought to exist? For design things like this, I like to sketch out some example clients as I do it to make sure that I'm not "generalizing from zero samples".

Sure, I have example code, but not actual examples that follow the rules specified. Since you need to provide everything that can be used in the plugin, I have some toy examples, but nothing that seems close to a future plugin for Vidalia.
The first plugin that I'll build would be the one that starts Firefox for TBB.
I could code the plugin before being able to run it (may be this was what you meant?).

I'm mainly hoping that you've thought of more than just one or two things to do as plugins, and that you've thought through them in enough detail to be sure that your framework will handle them, and that there aren't any parts of the framework that aren't there because of some actual requirement.

I don't have an extensive list of plugins to do. The idea of all this started (at least with me, Matt had this in mind for a bit longer I think) because Vidalia is handling things like launching a proxy, browser, IM, when it's a Tor Controller. And that ends up with either a lot of #if define(...) or Erinn having to patch certain parts because of different paths in different platforms, and so on. The same applies to auto-updates, and with certain advance configurations, etc.
So a plugin will need to be able to handle all this things. How exactly will it be able to handle it? As close to how you'd handle it with C++ and Qt. And this will mean to build interfaces to certain key parts of Qt, all the widget, and key Vidalia classes like TorControl.

This design document was intended to define how the plugins and Vidalia will get along, seeing a plugin X as a black box and assuming that it can do almost anything, and asking myself: "how will it interact with the rest of Vidalia?". I should have defined the exact scope of the document.

comment:5 Changed 8 years ago by chiiph

Status: newneeds_review

I've implemented this part of the framework in my branch chiiph/plugin.

Currently, there's a dummy interface to VidaliaTab that I used to test the workflow. I'm going to start working on interfacing a couple of more useful Qt classes, and the TorControl class, to make a first (more useful) plugin.

Regarding the API, it will follow Qt's already defined API for the different classes. What would differ might be the availability of methods, since interfacing everything in Qt will take a while (if it ever comes to that). So I need to think of a way of documenting which methods are available without duplicating Qt's doc.

Here are a couple of plugin ideas: tbb interface, obfsproxy, an advance dialog for the exit policies, a thandy interface (whenever it's functional), custom circuit handling.
I can see a lot of other possibilities if, for example, QtNetwork follows as it should the proxy settings.

comment:6 Changed 8 years ago by chiiph

An update:
qtscriptgenerator brings the whole Qt framework to the plugins, with just adding importExtensions("qt.core") and the same for qt.gui and so on. Which leads to the possibility of doing absolutely anything you can do with Qt in a plugin. Is this too much? I'm not sure yet, for now I'm happy that it seems to work perfect.

So right now I'm working on making the integration as clean as possible, and then interfacing TorControl.

comment:7 Changed 8 years ago by chiiph

Resolution: implemented
Status: needs_reviewclosed

This feature has been merge to the alpha branch. It will be present in the 0.3.1 release.

Note: See TracTickets for help on using tickets.