gtg-gsoc team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Fri, May 21, 2010 at 09:20:09PM +0200, Luca Invernizzi wrote:
> On Fri, May 21, 2010 at 01:48:14PM -0400, Paul Natsuo Kishimoto wrote:
> >  * '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?

We should probably avoid using 'Virtual' in class names; especially in
object oriented situations that implies certain behaviors that aren't
relevant in this case.

Generally the '<something>Type' object pattern is used when you want to
do dynamic typing, so not really what you want to use for parent class
names.  

I've seen prepending of 'I' for indicating interface classes, so
'IBackend'.

OTOH, I've also seen plenty of cases where some basic term is used for
base classes, so just 'Backend' would be appropriate, so long as it's
clear that it's an abstract class.  I've also seen naming like
AbstractBackend, GenericBackend, BaseBackend, RootBackend, but those
extra words always seem superfluous.  Just 'Backend' is usually plenty
good.

So, I think I agree with Paul's suggestion of 'GenericBackend' →  'Backend'

> >  * 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 :)

The Factory pattern is *really* common, and here I again agree with
Paul.  Maybe some programmers won't know what it means, but I'd say in
those cases this might be their opportunity to learn.  ;-)

Googling 'Python Factory Pattern' should probably turn up suitable docs.

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

Well, maybe we should look at what data actually needs set up in order
to establish another BackendType and/or Backend.  That'd help identify
whether my idea for doing it across dbus is feasible or if I'm just
insane (both may be possible too).

Does installing a new BackendType require adding python code to the
system somewhere?  Does the gtg backend have the ability to call out
dynamically?  (So you could start gtg, then put the code for the backend
type on the filesystem somewhere, then tell gtg to make use of that code
for instances of the new BackendType.)

If that is not possible, then yeah we're going to require that
installation of new backend types requires using the packaging system
(or make install or whatever), and restarting gtg.  In this case, having
dbus calls or plugin api's aren't really going to make much sense.

However, even so, instantiating a new backend instance of an already
installed BackendType could be feasible to do across dbus, and so could
be something a plugin could do I guess.

> >  * 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).

Ahh, that's right.  Hmm, this plugin is misnamed, it kind of implies it
does sync with bugzilla.  Maybe 'AutoLink' or 'BugConnect' or some such
would be more descriptive.

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

Aren't tasks identified as N@M, where M is the backend number?

Bryce