gtg-gsoc team mailing list archive

[Karlo Jež <karlo.jez@xxxxxxxxx>]

Lovely code Luca! :)

I agree with the plugin / backend separation. A well behaved plugin should
not care where the tasks come from.

I'm wondering about multiple users. How should that be handled at the
backend level? I understand that localfile works great for desktop because
every user has a home directory. But what about the server (which is running
as a single user)? 1000 users shouldn't read/write to the same file, so I
figure we'll have to make a slightly different backend for the server. I'm
thinking about having separate files/folders/backend instance for each user,
similar to the way the localfile backend does it now,. On the other hand we
could make a database, but I think that will require us to change the
backend system to allow for queries, which is ugly.
I think it would be better to keep feature creep as far as possible from the
backend system to keep it clean, and just implement it on the server with a
custom backend.

So, once again, nice job Luca, especially for supporting multiple backend
instances! :)

On Fri, May 21, 2010 at 9:20 PM, Luca Invernizzi <invernizzi.l@xxxxxxxxx>wrote:

> 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<https://launchpad.net/%7Egtg-gsoc>
> > Post to     : gtg-gsoc@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~gtg-gsoc<https://launchpad.net/%7Egtg-gsoc>
> > More help   : https://help.launchpad.net/ListHelp
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJL9tznAAoJEJwV7kAnLtWz3nIP/3L8ibqPwF4u80WdCRZcfBcy
> edvvFNHm56XXI62dsLP7mfT+lZxbsXkE1fqDI2jRdKQ1GCUnSy1aJwsNlIdJIDIL
> DP7sQL9CMHO2uGqapnp/Wh93jKeY7U7NWog3pyfZz/MyByS4UGBmEKJU2+70MUrK
> 3J3cFPo+uIc/Z+zpP+x5+HjuubkPIYOya3p5qYOGoLY87N0GWqvN2qG0q1wQnDkF
> RivrLJr8IsoLQr9/BNItxFl3BqVCP4xPox8DLsK3f2uWHLAoW0cHfjFNjqLT4K65
> zQV8ifFM7m9e6VniahNn/Hgt1jOz02Y7gLBA1jeedKZv2dd3bAR50rU9ThPLlPAP
> O1OV7d2pMOqfVtaaWPxXEJoTb0QVAUdx+zFq93oN9qLLOT8+AyUuAPQnG+vX6opy
> jK10vw44xFIhRr7o8lv1yc9E5NbVUTplO231g8qGrLWehrAFiBjbjHwkUiIrOKyF
> uHOD6mglO5hGWciJTTzVp+5L5wVXSnoNWEdJto/p6mFOHIIGoGHOew7QNVz7B2lQ
> NdP4Q0b4k1bNxyvY9qdfmcMMlF0wg8xvWvBF2AO7ogIxjcdONHU1JTqk9phnTfof
> ObtC1duxCkQsiofyDUHQxUwZsdpsWfSqDhdfAAuS6soClEldYXbB8M2aPqCIEtGE
> AZ1p/M/EJZcYKfZ1Cns7
> =hmbh
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-gsoc<https://launchpad.net/%7Egtg-gsoc>
> Post to     : gtg-gsoc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-gsoc<https://launchpad.net/%7Egtg-gsoc>
> More help   : https://help.launchpad.net/ListHelp
>
>