Re: Starting to contribute.

["John Carr" <john carr unrouted co uk>]

On Jan 15, 2008 4:17 PM, Govind Salinas <govindsalinas gmail com> wrote:
>
> Hi,
>
> My original plan was to store the todo items on the mugshot server.  After
> poking around for a bit I found that I would probably have to make some
> server updates (adding classes to support the new resources).  I also
> appears that the intention is to use other services for this sort of thing.
> So I went and I tried to see if Google could provide anything, and they
> don't directly (I *could* reserve a google doc or some such thing and use it
> to store the todo information, but its a bit of a hack).  So now I am stuck
> without a place to store the data.
>
> So, should I go back to my original idea and make server classes to support
> a todo list or is there some other service out there that I should use for
> storage.
>
> Advice is appreciated.
>
> Thanks,
> Govind.

We (Conduit) are in a similar situation. If the correct object types
are available we would easily be able to sync (from any of our
supported endpoints) Contacts, Calendars, Todo items, Notes, Photos,
GConf and others to Online Desktop.. So first I would like to throw a
crappy idea at you, and if it can't be beaten into a sensible idea by
one of the devs, then advice on how to move forward on the different
object types we need is sought.

*Crappy strawman type idea to stimulate discussion*: I was wondering
if we could organise a generic object type that teams could use until
a better object was available for feeding data into the online
applications? The use case here is that a fat client can use online
desktop and its always up to date notifications as a back end data
store. For example, I can change a value in my application and it is
immediately stored in online desktop and any other clients that are
online (like my N810) can grab this data. This idea alone is certainly
not good enough to be acceptable - among other things, some thoughts
are needed on how to handle migration when a more suitable object type
becomes available.

If a variant of this is acceptable then I had thought about:

uid
lastModified
type
blob

Type would be so that conduit could retrieve all "conduit.contact"
blobs for the current user. Blob in that case would be some vcard
data. If such an object were possible then Conduit users, for example,
would be able to sync their address book, calendar, tasks, tomboy
notes and more between all their PC's and Maemo devices BY GNOME 2.22.
I'm sure such levels of awesome would drive both projects forward...
Feedback on how to move this forward welcome.

If its not acceptable/possible/sane then I would like to open
discussion on how Contact, Calendar, Task and Note data might be held
on the server. For example, would each field of a VCARD or VEVENT
object have to be exposed as an object property? From what i've seen
of the client API, i'd have to ask for each field i was interested
in... That seems like a messy query when i'm trying to sync a full
object.. or am i overlooking something?

What about Notes? Tomboy notes have a custom markup. This is used to
format the note in tomboy, how should online desktop see this data? In
terms of replicating it between my workstations, there is also meta
data that is not part of the note itself, but stored with it... So in
terms of getting started and being able to access my data anywhere I
have GNOME and internet, a generic blob is by far the easiest approach
but also by very far the least useful when it is time to think about
"Tomboy Online" type services..

Sorry for the rambling... Thoughts, ideas, directions.. :-) How do we
get started!

John