Re: Module proposal: Project Hamster for GNOME 2.24

[Toms <toms baugis gmail com>]

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 <patrys pld-linux org> wrote:
> On Wed, Apr 16, 2008 at 3:20 PM, Toms <toms baugis gmail com> 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
>