gtg-gsoc team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

Answer to Bryce
On Fri, May 21, 2010 at 01:48:14PM -0400, Paul Natsuo Kishimoto wrote:
>>  * For backends offered by plugins, does the PluginManager notify the
>> BackendTypeManager that a new backend is available, or does the latter
>> query the former?
>> 
>>         (This also makes me wonder if it is worth distinguishing
>>         backends and plugins, i.e. no longer "plugin X provides backend
>>         Y". If we later have client (UI) / server separation, plugins
>>         will go with the client, backends must stay with the server,
>>         roughly.)
>
>Yeah I think you're probably right here.  Maybe the right interface is
>to have dbus calls for registering/querying/etc. backend types, to
>enable it to be possible to register the new backend from the GUI.
>
>If this were done, then while internally backends would be a separate
>concept from gui plugins, to the user they could be considered one and
>the same (in fact we could let the plugins themselves register backends
>if they desire, so if someone wanted to make a combo plugin that
>includes both client gui features and a new backend, they could package
>it all up in one piece, and the user would only have to install one
>thingee.)

I think that expanding the BackendFactory to support backends types stored
elsewhere wouldn't be much of a problem. After all, it just need the specific
backend class to work, and how it is obtaining that it's up to us.
However, for now I'll keep things simple and expandible, loading backends just
from the backend dir. Those feature will come afterwards :)
>
>>  * I think there is/was a Bugzilla plugin, I think (never used it). If a
>> user wanted to convert bugs from *two* Bugzilla databases into tasks (or
>> equally, keep tasks in two sets of local files, etc.), how would that
>> parallelization be handled? Multiple backend instances? How would config
>> be stored/distinguished?
>
>Aha, so this is a perfect use case for what I just described.  The
>"Bugzilla Plugin" would be a GUI dialog for the user to specify bugzilla
>bug trackers, their login credentials, and so on.
I understand what you want to mean with the example, but these features will
be supported by the backend system itself. Of course, there will be always some
weird 15-phases authentication system that will be incompatible with the code, so 
it's possible that there will be a need for a plugin.
>
>When first enabled, the plugin would register a "Bugzilla Backend Type"
>via dbus to the gtg backend.  Then as the user uses the dialog to hook
>up several bug trackers, it makes dbus calls to instantiate a new
>'bugzilla backend instance' for each tracker.  Maybe the user has
>different credentials for each.
>
>Bryce

[cut and paste between mails]

> > >  * 'GenericBackend' →  'Backend'? Compare with, e.g.
> > > http://docs.python.org/library/exceptions.html#exception-hierarchy .
> > > Code would be slightly less verbose. By definition, parent classes are
> > > more generic than derived classes.
> > It's true that parent classes are more generic by definition, but I like verbose
> > code because  it helps in  reading. We  could do GenericBackend  -> BackendType?
> > GenericBackend  is not  really a  backend, it's  a backend  interface with  some
> > additions. Anyway, refactoring names can come any time, it should not be an
> > issue. Any proposal? VirtualBackend?
> 
> We should probably avoid using 'Virtual' in class names; especially in
> object oriented situations that implies certain behaviors that aren't
> relevant in this case.
> 
> Generally the '<something>Type' object pattern is used when you want to
> do dynamic typing, so not really what you want to use for parent class
> names.  
> 
> I've seen prepending of 'I' for indicating interface classes, so
> 'IBackend'.
> 
> OTOH, I've also seen plenty of cases where some basic term is used for
> base classes, so just 'Backend' would be appropriate, so long as it's
> clear that it's an abstract class.  I've also seen naming like
> AbstractBackend, GenericBackend, BaseBackend, RootBackend, but those
> extra words always seem superfluous.  Just 'Backend' is usually plenty
> good.
> So, I think I agree with Paul's suggestion of 'GenericBackend' →  'Backend'

I can't use "Backend" for the GenericBackend because in each backend module
there is a class "Backend", which has always the same name (comes from Lionel
code and it's very handy codewise). Now, I can change that into something else
if you want, but keeping both named "Backend" would be an unecessary clash in
the namespace. For now I'll keep GenericBackend, we can always refactor
that once a good solution is found.
>
> > On Fri, May 21, 2010 at 01:48:14PM -0400, Paul Natsuo Kishimoto wrote:
> 
> 
> > >  * Among the roles you give BackendTypeManager is "construct a new
> > > backend and restore a backend from an xml object." That is dealing with
> > > instances, not types, so the name is not 100% descriptive. This concept
> > > is sometimes called a 'factory' → 'BackendFactory'?
> > I thought about that, but:
> > - I wanted to stress that it handles types
> > - I'm not sure if everybody knows what a factory is, and
> >     class BackendFactory(Borg) maybe is a bit too computer scientish :)
> > Anyway, now that you brought it up I will change it :)
> 
> The Factory pattern is *really* common, and here I again agree with
> Paul.  Maybe some programmers won't know what it means, but I'd say in
> those cases this might be their opportunity to learn.  ;-)
> 
> Googling 'Python Factory Pattern' should probably turn up suitable docs.
ok, done.
> 
> > >  * For backends offered by plugins, does the PluginManager notify the
> > > BackendTypeManager that a new backend is available, or does the latter
> > > query the former?
> > > 
> > >         (This also makes me wonder if it is worth distinguishing
> > >         backends and plugins, i.e. no longer "plugin X provides backend
> > >         Y". If we later have client (UI) / server separation, plugins
> > >         will go with the client, backends must stay with the server,
> > >         roughly.)
> > I always thought plugins and backends  to be completely separated things. I find
> > that saying to a user "enable plugin X  and you will have backend Y available to
> > configure" is extremely confusing.
> > In my idea, Backends do their job alone.  if a plugin wants to mimick a backend,
> > it will have to do it by itself (I mean, it will need to contain all the code to
> > do  that or  to trick  somehow the  normal flow  of GTG  - like  the RTM  plugin
> > currently does).
> > I really  don't see  how providing  a normal  Backend though  a plugin  would be
> > useful.  Maybe you  could  help me  here.  The plugins  which  currently act  as
> > backends will continue to work normally.
> > 
> > In short, I see Backends working at the very bottom of GTG layers, while plugins
> > work at the very top, alongside with the UI.
> 
> Well, maybe we should look at what data actually needs set up in order
> to establish another BackendType and/or Backend.  That'd help identify
> whether my idea for doing it across dbus is feasible or if I'm just
> insane (both may be possible too).
> 
> Does installing a new BackendType require adding python code to the
> system somewhere?  Does the gtg backend have the ability to call out
> dynamically?  (So you could start gtg, then put the code for the backend
> type on the filesystem somewhere, then tell gtg to make use of that code
> for instances of the new BackendType.)
That's possible. It's just a matter of updating the backend list (well,
dictionary).
> 
> If that is not possible, then yeah we're going to require that
> installation of new backend types requires using the packaging system
> (or make install or whatever), and restarting gtg.  In this case, having
> dbus calls or plugin api's aren't really going to make much sense.
> 
> However, even so, instantiating a new backend instance of an already
> installed BackendType could be feasible to do across dbus, and so could
> be something a plugin could do I guess.
> 
> > Anyway, if I want to have multiple  instances of the same backend type (say, two
> > xml files,  or two RTM)  there won't be  problems code-wise. The  code currently
> > supports multiple backend instances. It can tell which is which because each one
> > has a  pid, which  is stored  in the configuration  file. I'm  currently running
> > tests with 3 local files.
> > Keep in mind that  I haven't yet written the code to decide  what task to select
> > if two backends present a task with the same id. That will be the next step.
> 
> Aren't tasks identified as N@M, where M is the backend number?
Yes, but since now we have multiple backends, we just use uuids for tasks.
That's because a task can be stored in multiple backends, so a solution like
id@backend@pid would be a very good one.

Thanks for the suggestions!
  Luca

Attachment: signature.asc
Description: Digital signature