On Wed, Jan 06, 2010 at 11:03:36PM +0100, Lionel Dricot wrote: > > > That's fine to read task, but how will the user define in which backend > > > he wants to store a specific task ? > > > > > > > Why would someone need more than one backend for storing a specific > > task? Why not have a document-based approach where users can open a > > task database and read & write from there? > > I think I've replied to that with my example. Simpler example : Bryce > Harrington is already working on a launchpad backend. But, of course, he > will want another backend for his personal stuffs.
Right, but a given specific task would be in one or the other, not both, yes? > > > * Read-only displays a list of tasks that you have to do but you should > > > trigger something external to close them. It might be useful for > > > backends like bugzilla (at least as a first step) or for centralized > > > backend where your boss have to acknowledge that you finished a task. > > > > AIUI, the _only_ thing this gives you that import backends don't is > > that it stops you from editing the tasks. > > > > In that case, rather than having multiple types of backends, why not > > have a property on tasks that says whether or not that task is > > read-only? > > Not at all. If you have a read-only backend, they can still be modified > elsewhere. When you use an "import" backend, you create new tasks in > your existing default backend. > > Do you see the difference ? In practice it sounds like the difference between these two different kinds of backends is going to get blurred a lot. Is there really any value in differentiating about RW vs RO backends? For example, launchpadlib can operate both in "read-write" mode and in "read-only" mode at the user's preference during the authentication step. So this one backend can provide both "read-only" and "read-write" tasksources for the user. For tasksources I see some benefit to distinguishing between RW/RO, but it seems like doing this as an attribute on the tasksource object would suffice. > > Or couchdb by default. > > I'm not sure it would be a good default as we cannot consider that our > users use couchdb. But it's a discussion we could have once I've > implemented support for multi-backends. > > I personally use Ubuntu One so I'm pretty sure I would use a couchdb > backend ;-) The default should probably be whatever gets the best testing. It could be made a config-time option, so that distros which lack couchdb can configure their package to use the text file backend or whatever. Bryce _______________________________________________ Mailing list: https://launchpad.net/~gtg-user Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-user More help : https://help.launchpad.net/ListHelp
