Le samedi 22 mai 2010 à 11:53 +0200, Luca Invernizzi a écrit : > On Sat, May 22, 2010 at 9:38 AM, Lionel Dricot <[email protected]> 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 > >> i...@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. > We have also to consider that a fair set of r/w backends will not > support a series of features that GTG taks have. Take subtasks, for > example. > Say that I'm an unexperienced user, with my own tasks set, and I > configure a Launchpad backend. I espect to be able to move the new > imported tasks (Launchpad should be a read only backend) and place > them under my task/project "become a great FLOSS guy" and maybe tag > them @FLOSS.
Tasks from RO backends should not be modifiable at all. No way to add a tag, move it or change the parent. It's read-only. The interface should reflect that. > Now, that's not supported by the backend. We can follow two ways here: > 1) don't allow the user to do that. We have to explain him why he > can't do that, though, so a fair amount of code has to be written in > core. See above. Read only backend. Thus, you can only read the task. > 2) allow him to do that, but forget about the changes on restart > (which may be confusing and annoying) More than confusing, it would be a bug ;-) > If we have the "multiple backends per taks", we can do like the RTM > plugin does: we don't touch attributes that we don't know. So, for > example, subtasks are possible in GTG, but this information is not > forwarded to RTM. Still, a user can exploit all functionalities of GTG > while using the software. What if you modify the task with the RTM backend disabled. And what if you open it from another computer ? Having the same task in multiple backend allow a lot of broken usecase. When do you copy or move a task ? > > Another problem is: this tag is tagged @Localfile @RTM. Now what I do? For me, that's the only real problem related to having one backend per task. It could be solved by : 1) defining some "order/priorities" in the backend (difficult part is having a good UI for that) 2) Having a clear message in the UI when a task change its backend (I see something like the yellow Gedit "file has been modified" warning). Also, features not supported by a backend should not be usable with task in that backend. For example, subtasks could not be used with RTM backend. That's why, since the beginning I made the backends advertising its features. It's make, IMHO, a lot of sense. The subtask features is not enabled, button is greyed out and a tooltip says : "This task is saved in the backend %s which doesn't support subtasks". I foresee *a lot* of complications if we allow multiple backends per task. I foresee *a lot* of situations where there will be no way to get the right behaviour. On the other hand, I don't see so many usecase where only one backend per task would be a limitation. I mean, currently in Evolution, each mail is associated to one IMAP account and it's not really a limitation. 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 >From my perspective, it is clear that, as long as I'm not convinced by a specific usecase where 1 task/x backend would be very useful (and I don't see any, so far), I think we should go the "1 task/1 backend" way. I know that I changed my mind. It was exchanging mails with all of you that convinced me. 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. _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
