← Back to team overview

gtg-gsoc team mailing list archive

Re: Invernizzi - GSoC code review

 

On Sat, May 22, 2010 at 11:53:25AM +0200, Luca Invernizzi wrote:
> On Sat, May 22, 2010 at 9:38 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> > Le samedi 22 mai 2010 à 01:39 +0200, Luca Invernizzi a écrit :
> >> > Aren't tasks identified as N@M, where M is the backend number?
> >> Yes, but since now we have multiple backends, we just use uuids for tasks.
> >> That's because a task can be stored in multiple backends, so a solution like
> >> id@backend@pid would be a very good one.
> >
> > Luca > From my long explanations a while ago, it appeared that having
> > tasks stored in multiple backends would be a huge problem (conflict
> > handling) and not specially intuitive nor useful.
> >
> > It was decided to have task only in one backend (if I remember, the
> > discussion was mainly with JML).
> >
> > My suggestion for now :
> >
> > 1) consider that each task is in one backend and only one.
> That's fine for me, because it makes my jobs easier :)
> However, from my experience in the RTM plugin, I don't think that
> conflict handling would be a huge problem: you just have to compare
> modification times.

Despite I guess sparking this thread, I don't really have a strong
opinion here.  :-)

I seem to recall writing up a use case favoring multiple backends for a
given task once before, but I no longer remember the details.

In general though, I think having the simplification of one backend per
task could help us sidestep situations where weird, deep bugs could
appear.  And it may make implementation of core logic a bit cleaner.
But I say this without any insight into what the code will actually look
like.

Perhaps what's needed is to define and write down a few use cases where
multiple backends would be a possible solution.  And then analyze them
to see if there are ways to achieve the same functionality without using
multiple backends.

I don't think it's necessary to go as far as making a blueprint, but
Luca maybe you could take your launchpad backend example and write it up
in a bit more detail in wiki somewhere?  Maybe an RTM use case too.
Then we can be more organized at studying the pros and cons.

Bryce



References