Hey,
Sorry to stick my nose in on this, especially if I'm missing something.
But do you guys have anything decided about this, and what it is all going to be stored on? May I suggest using SQLite for the data storage? It is very lightweight, not much ram or processor use needed, unlike parsing big XML files... and I'm sure it'd be easy implemented in the core libraries? Because this way, other applications could read from these data-stores directly, or there could be a standardized API for applications to access that could make the information available in these open formats =].

Not sure if I'm totally barking up the wrong tree here... so please correct me if I am wrong....

All the best,
Samuel Melrose
[EMAIL PROTECTED]

On 20 May 2008, at 18:20, [EMAIL PROTECTED] wrote:

Am Fr  16. Mai 2008 schrieb ian douglas:
MartinG wrote:
On Friday 16 May 2008 03:26:06 Carsten Haitzler wrote:
yeah. this is actually the bigger problem we face in the longer run.
standardising data stores and access to them etc. :)

I think this is a important point that should be given some thought
before everyone starts hacking. Would it make sense to use opensync
[1] as a middle layer between the frontend app and the backend store
-- with one plugin on each side?


Yeah, there was a big discussion about this a few months ago, talking
about whether to store data in some generic format or some homemade XML format or using some middle layer tool like opensync, and synchronizing
data to a remote location periodically versus sync'ing only when
connected to a PC, etc. It was a pretty thorough discussion.

Personally, I like the opensync idea, a platform-independent sync
engine, that can be ported to the OpenMoko platform.

So was there any decision/consensus on this topic?
I think it's a very "mission critical" thing to have a decent lib API defined from the very beginning - see KDE addressbook, other resources of Kontact and the neverending story about the *abc*-libs to use them from "outside". LDAP, WebDAV/GroupDAV and even IMAP resources come to mind :-/. Have a look to
Kontact|contacts|resources|add...
Same thing for calendar etc...

/jOERG

_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Reply via email to