[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3215 [Vidalia]: RFC: Plugin framework design
#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