gtg-gsoc team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

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

> _______________________________________________
> 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


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

Attachment: signature.asc
Description: PGP signature