Re: [tor-bugs] #3215 [Vidalia]: RFC: Plugin framework design

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#3215: RFC: Plugin framework design
-------------------------+--------------------------------------------------
 Reporter:  chiiph       |          Owner:  chiiph       
     Type:  enhancement  |         Status:  new          
 Priority:  normal       |      Milestone:  Vidalia-0.3.X
Component:  Vidalia      |        Version:               
 Keywords:               |         Parent:               
   Points:               |   Actualpoints:               
-------------------------+--------------------------------------------------

Comment(by chiiph):

 Replying to [comment:3 nickm]:
 > Replying to [comment:2 chiiph]:
 > > Replying to [comment:1 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3215#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs