Standardizing data store across toolkits (SMS, PIM data, playlist, etc)

Samuel Melrose sam at feel-the-darkness.co.uk
Wed May 21 12:04:40 CEST 2008


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
sam at feel-the-darkness.co.uk

On 20 May 2008, at 18:20, joerg at openmoko.org 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 at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community





More information about the community mailing list