Unified PIM

[thomas.cooksey at bt.com]

>Yes, with the LiPS approach both sides could be satisfied... the LiPS
>PIM API is devided into an upper layer service API for applications to
>use and a lower layer Enabler API for connecting backends.

Yes, sorry, I should have been clearer in my initial post. I meant that we use something like EDS to sync to a server then both Qtopia & OpenMoko applications use EDS as a backend, with it's cached dataset. I didn't mean both Qtopia & OpenMoko maintain their own cached copies of data from the server... that would be... inefficient. :-)


>So for me it would make perfect sense to use the LiPS APIs and bring
>some flexibility to the applications.

Yup, if there's an API already defined why not use it? Plus if phone manufactures start to support the API (and looking at the LiPS member list, there's a lot of manufactures) it will allow porting to new phones that much easier. I'm sure I read on a list somewhere that LiPS member companies were sponsoring GPE phone edition development to produce an open source reference implementation of the LiPS APIs. If this is true, couldn't we use that implementation on OpenMoko?

The only issue is if the API doesn't give us enough functionality.


>Think, at current state of cooperation between projects (OpenMoko 
>Qtopia) synchronization with server is one of the very few ways (I'd
>prefer to see SyncML; there are few of free and commercial servers
>supported this protocol already).

Where does SyncML relate to the LiPS APIs? According to http://www.linuxdevices.com/news/NS7946047145.html LiPS and OMA have formed an alliance ('bout time).


Cheers,

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3504 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/community/attachments/20070927/f1f81a7a/attachment.bin