I'm concerned that this kind of mapping is cheating in a way - trying to put one terms under others, putting hamster data in some invisible calendars (evo will get crowded otherwise) and so on.
Synchronization is certainly a win, but not too big, considering all the woodoo going on in background. And it is certainly not a task done by swift move of a hand. At the end we could hit the wall because there are currenty unforseen aspects that are needed for hamster, but bringing them into EDS might abuse EDS structures. I would like to keep hamster separate from Evo. If somebody comes up with a reasonable model, migrating data afterwards should be quite easy - having hamster's data in sqlite for now shouldn't be a show stopper. On Wed, Apr 16, 2008 at 2:35 PM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: > On Wed, Apr 16, 2008 at 3:20 PM, Toms <[EMAIL PROTECTED]> wrote: > > Are there any specific considerations why data should be stored in EDS? > > Also i'm quite affraid to pollute EDS with tasks, that are basically > > not tasks but fact constations instead. > > I think we can use the default calendar to store the information > instead of SQLite. We don't have to store past tasks anywhere, just > query EDS about all entry titles in the past month or so (gives us > autocleanup). Calendars are categories, TODO items are tasks. This > would allow for easy sync between several machines (using Google > Calendar for example) but would result in all past dates being > highlighted by the clock applet. What do the others think? > > > > -- > Patryk Zawadzki > PLD Linux Distribution > _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list