gtg-contributors team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Sat, May 22, 2010 at 12:25:21PM +0200, Lionel Dricot wrote:
> So, to summarize what I see :
> 
> 1 task/1 backend:
> Strengths : 1) consistent user experience guaranteed  and 2) easy to
> implement
> Weaknesses : 3) There should be some priorities between backends and the
> UI should reflect this
> Opportunities : 4) Quickly implemented and fixing corner usecases later
> Threats : 5) Missing some corner usecases where having multiple backends
> would be useful (Is there some example of such usecase ?)
> 
> 1 task/x backends:
> Strengths : 1) Cover almost every usecase
> Weaknesses : 2) Hard to implement 3) Could lead to very complicated user
> experiences 4) Need to discuss a lot of possible usecases and problems
> to do the design
> Opportunities : ?
> Threats : 5) Trying to cover every usecase and just not be good at any
> 6) Taking too much time and missing the boat, letting the user
> enthusiasm sinks


> I admit that, at first, the "1 task/x backends" sounds sexy but, in the
> real world, I fear it would be only a geek masturbation and would harm
> our targeted users.

Haha, no maybe it could be useful for certain use cases, but I
definitely agree it's conceptually a good bit more complicated, and as
such we're more likely to make mistakes or logical omissions.  Or if we
don't, other contributors we welcome might.


Let me ask, is single-backend vs. multiple-backend something that needs
to be decided right now upfront?  If it is an enhancement that could be
added later, then if it really is needed, won't the need make itself
known as we go forward?  Then we can worry about implementing it and
dealing with whatever corner cases come up at that point.

If it's something that would require major changes and break existing
stuff, then another option would be to do the experimental development
on a branch and then register on the roadmap when it will land, and then
plan out migration strategies and so on to minimize the impact.

I'm thinking the single-backend-per-task model is useful enough I think
we could get a lot of mileage out of that alone, even if we do think
we'll need multibackend ultimately.  And I'm guessing (but don't really
know) that refactoring single-backend into multiple-backend some day
later is a feasible strategy.  But like I said, it'd help to understand
it if we had some detailed use cases to study first.

Bryce