gtg-gsoc team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

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.

 * 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'?

 * 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 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?

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

Attachment: signature.asc
Description: This is a digitally signed message part