gtg-gsoc team mailing list archive

Thread
Date
Re: Invernizzi - GSoC code review

To: gtg-gsoc@xxxxxxxxxxxxxxxxxxx
From: Karlo Jež <karlo.jez@xxxxxxxxx>
Date: Sat, 22 May 2010 01:42:53 +0200
Cc: Bryce Harrington <bryce@xxxxxxxxxxxxx>
In-reply-to: <AANLkTik3zZ4ptaVASlmY8FbbV80rUHXuOMdpBCvFysNl@mail.gmail.com>
Multiple users feature is relevant only to my project. ;)
gtg web server will access tasks via the same dbus server that will be used
in desktop gtg.

On Sat, May 22, 2010 at 1:23 AM, Luca Invernizzi <invernizzi.l@xxxxxxxxx>wrote:

> On Fri, May 21, 2010 at 10:18:09PM +0200, Karlo Jež wrote:
> > 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.
> This "multiple users" feature is new to me. I thought we would carry out a
> server/client division similar to the one in gwibber (server and client run
> for
> a single user, it's just a matter of wanting to keep the server alive to
> speed
> up the client, better integrate with the desktop and such).
> Anyway, yes, I think we could have a separate backend per user without too
> much
> change.
> >
> > So, once again, nice job Luca, especially for supporting multiple backend
> > instances! :)
> :D
> >
> > 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>
> <https://launchpad.net/%7Egtg-gsoc>
> > > > Post to     : gtg-gsoc@xxxxxxxxxxxxxxxxxxx
> > > > Unsubscribe : https://launchpad.net/~gtg-gsoc<https://launchpad.net/%7Egtg-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>
> <https://launchpad.net/%7Egtg-gsoc>
> > > Post to     : gtg-gsoc@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~gtg-gsoc<https://launchpad.net/%7Egtg-gsoc>
> <https://launchpad.net/%7Egtg-gsoc>
> > > More help   : https://help.launchpad.net/ListHelp
> > >
> > >
>
> > _______________________________________________
> > 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)
>
> iQIcBAEBCAAGBQJL9xW9AAoJEJwV7kAnLtWzTMAP/jDpa1iduUvsVy3WpXSEK5ue
> f3cu3u/lpW/WdDnxJz6hNZ61nFQ6H0uLGLCxjqMZ78iL2MOzAqtYceaaiLrkaahZ
> T6fB2LQSr+39H3RKaFzaSB0ZA8sW9sRHBj3vLjiI+M2txErrahhcng98oLNLNIJI
> nCjzimymxlktohltM5gO9MOfs+XS6FthTkKVGw/rvmNuIJPTykn1hb936gt+L5Lf
> 95BoVk/qb+9rkTZOUiveVAQPQaNJSMxUUWIjhyJj4mkic8eAZSxRY4hzKO+S2QFX
> Q4D2sDtccgwLIEbOw78+lq/VYYiNnsmpaKqgdMFEkWqi7Pt7mERImcBa4rowc80t
> 6hyJY0mHBXViV1TAqCIvPfx76BnKP2HIbjBMxVVkBmRWbf8rw2CwMKZaRnwHc1DD
> dXPLifVq7trgSm9HoVb8mUQAW/l4u6R6xEHEsmxNfzSnznNLHan7idmM7JtxB18n
> ejoARD8hIeRS+vveBROKkRQ6h9WZ/Tnipv1spEihD46V8xCOgXlsDbxwqZH5qsoa
> n4rxkmlqo8PxzdTS761Rkgj1nv1xg+mI6nOAzyfuwocQpJz+JrrcCPQhXFSG9mQj
> iomtvC5gpjjjB/t6SCXvRpANXX56JCQ1lfPap/JpHiOunDl3XPf8ASIFNfthD6Id
> +jgAYnfppOyxP68nQxWX
> =5sJx
> -----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
>
>
References

Invernizzi - GSoC code review
From: Luca Invernizzi, 2010-05-21
Re: Invernizzi - GSoC code review
From: Paul Natsuo Kishimoto, 2010-05-21
Re: Invernizzi - GSoC code review
From: Luca Invernizzi, 2010-05-21
Re: Invernizzi - GSoC code review
From: Karlo Jež, 2010-05-21
Invernizzi - GSoC code review
From: Luca Invernizzi, 2010-05-21