gtg-user team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

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