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 _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
