gtg-gsoc team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

On Fri, May 21, 2010 at 01:48:14PM -0400, Paul Natsuo Kishimoto wrote:
> Luca, thanks so much for this explanation — I was just about to beg you
> for it :)
> 
> The approach makes sense. I have only a couple minor semantic quibbles
> and some questions:
> 
>  * '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?
> 
>  * 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 :)
> 
>  * 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.

> 
>  * 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?
The bugzilla plugin  doesn't work as backend,  it adds to the  current task some
information  about the  bug once  a  bugzilla link  is  pasted (if  I recall  it
correctly).
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.


Hey, thanks a lot for reading!

Luca



> 
> On Fri, 2010-05-21 at 16:16 +0200, Luca Invernizzi wrote:
> > Hello there,
> > I'm  going to  briefly explain  the  architecture brought  up so  far about  the
> > multi-backends feature. Bryce, you're in Cc: since  I know that you read code as
> > bedtime stories..
> > 
> > My code is in lp:~gtg-user/gtg/multi-backends__invernizzi_gsoc/
> > 
> > First of all, backends exist in  two forms: backend instances (configured by the
> > user, the stuff  we have in projects.xml) and types  (which define the structure
> > of the backend). It's the same difference  that stands between "int" and "int i"
> > in C, so to speak.
> > 
> > Backends instances are dealt with in the datastore, as before. Backends type are
> > managed in  the new class BackendsTypeManager,  inside GTG/backends/__init__.py.
> > BackendsTypeManager is capable of listing the available backends type, construct
> > an new backend  and restore a backend  from and xml object. This  will also take
> > care (in the future) of checking if all the required modules are available.
> > 
> > 
> > A     prototype     for     all      backends,     GenericBackend,     is     in
> > GTG/backends/genericbackend.py. That  means that  all the  backends should  be a
> > derived class  of that. GenericBackend  describes the interface  backends should
> > have, how  to define a  backend general description (name,  description, icon..)
> > and how to describe the backend parameters and its default values. It will be in
> > charge of  handling all the common  things among backends, which  at the moment,
> > are  just the  "attached tags"  (tags for  which the  backends is  in charge  of
> > storing and loading tasks).
> > 
> > The Datastore  is now aware  that backends have attached  tags, and it  has been
> > refactored a bit (TaskSource too).
> > 
> > Having created the BackendsTypeManager, I've  also refactored the loading of the
> > backends in GTG/core/__init__.py (at the end).  Now, it should be clearer what's
> > happening. I had to change the format of  projects.xml (I had to add a series of
> > things -attached tags  ...), but I took  care that the code works  also with the
> > old format, and changes it on first loading.
> > 
> > 
> > Still alive? Good. This  is the briefest I could get. Tell me  if you didn't get
> > something or you found a weak side of this approach.
> > 
> > Ciao!
> >    Luca
> > 
> > ps: vim justifies text! Awesome..
> 
> -- 
> Paul Kishimoto
> MASc candidate (2010), Flight Systems & Control Group
> University of Toronto Institute for Aerospace Studies (UTIAS)
> 
> http://paul.kishimoto.name — +19053029315



> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-gsoc
> Post to     : gtg-gsoc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-gsoc
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: Digital signature