Re: Unified PIM
On Wed, 2007-09-26 at 18:49 +0100, [EMAIL PROTECTED] wrote: > >I guess my only comment is that while I don't really care which > >interface people use on their phones, it seems like the data interfaces > >should be the same... If I open up qtopia phone edition and look at my > >contacts or maybe even edit them and then close it down and open up my > >OM interface and look at them, they should be the same. All edit are > >visible.. No double entry. > > Agreed, but I'd take it one step further. Given the neo has an > internet connection, why can't PIM data be stored on a web server and > just cached locally. Couldn't you then integrate that into desktop PIM > applications too? > > Ok, so this isn't a new idea. :-) Evolution Data Server supports > integration to groupware backends, but from what I've seen, these are > enterprise-class groupware servers designed for corporations. I can't > seem to find anything designed for the consumer, an > internet-accessible groupware server I can sign up to and store my > contacts in a single place. > > The problem is not local - I'd be surprised if Embedded EDS couldn't > be adapted to store it's data on a server and just use a cached > dataset locally. The problem is that this requires some server > infrastructure and so far I've yet to find something which will do it. > Has anyone else seen this done? > Interestingly, there was a Google Summer of Code project to write a Google Calendar backend to EDS. See: http://ebbyw.wordpress.com/2007/08/30/google-calendar-evolution/ Regards, Thomas -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Unified PIM
>So for me it would make perfect sense to use the LiPS APIs and bring >some flexibility to the applications. I've just read through the LiPS API. I think it's a step in the right direction, but it looks like it's got a long way to go before it's usable. :-( I guess my main issues with it are: 1) It (currently) only covers address books 2) The Query interface is pretty limited (No way to "get contacts.phone-number where gender is Female and bra-size >= DD") 3) There's no "last updated" timestamp on the fields. This is an absolute must to make syncs reliable, otherwise how does it know which is correct if the server and the client have different values? I'm thinking that it could be a great interface to get at the address book on the SIM card and import it into a unified local repository (which then gets synced to a server somewhere on the internet). Perhaps EDS would be a possibility here? Cheers, Tom <>___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Unified PIM
>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
<>___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Unified PIM
Joshua Layne schrieb: > On Wed, 26 Sep 2007 18:49:43 +0100, <[EMAIL PROTECTED]> wrote: >>> I guess my only comment is that while I don't really care which >>> interface people use on their phones, it seems like the data interfaces >>> should be the same... If I open up qtopia phone edition and look at my >>> contacts or maybe even edit them and then close it down and open up my >>> OM interface and look at them, they should be the same. All edit are >>> visible.. No double entry. >> Agreed, but I'd take it one step further. Given the neo has an internet >> connection, why can't PIM data be stored on a web server and just cached >> locally. Couldn't you then integrate that into desktop PIM applications >> too? > I would prefer to not have a network dependency on PIM data. It might be a > nice extra feature, but I would like to see the core data held on the phone > supported by the different front-ends. I may want to switch frontends > without resyncing all my data. > > It seems like LiPS might be a good start for this shared architecture. As one being involved in LiPS I feel obliged to reply here ;) 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. So what an application would do is to use the service API and then you can use any application that conforms to that API without resyncing your data. Also for the backend, the application does not need to know where the data comes from, be it a network remote calendar or a local EDS contacts database. So for me it would make perfect sense to use the LiPS APIs and bring some flexibility to the applications. > In the event of a "non-compliant" implementation, perhaps > wrapper/abstraction scripts could be built to make it transparent to the > end user? I would prefer to use a standardised API... make things a lot easier. > Regards, > j. Cheers nils faerber -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Unified PIM
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). But also it is possible to synchronize different databases by using local files - just export/import procedures, maybe even automatically (on each start/stop for example). What do you think? VC [EMAIL PROTECTED] wrote: I guess my only comment is that while I don't really care which interface people use on their phones, it seems like the data interfaces should be the same... If I open up qtopia phone edition and look at my contacts or maybe even edit them and then close it down and open up my OM interface and look at them, they should be the same. All edit are visible.. No double entry. Agreed, but I'd take it one step further. Given the neo has an internet connection, why can't PIM data be stored on a web server and just cached locally. Couldn't you then integrate that into desktop PIM applications too? Ok, so this isn't a new idea. :-) Evolution Data Server supports integration to groupware backends, but from what I've seen, these are enterprise-class groupware servers designed for corporations. I can't seem to find anything designed for the consumer, an internet-accessible groupware server I can sign up to and store my contacts in a single place. The problem is not local - I'd be surprised if Embedded EDS couldn't be adapted to store it's data on a server and just use a cached dataset locally. The problem is that this requires some server infrastructure and so far I've yet to find something which will do it. Has anyone else seen this done? Cheers, Tom ___ 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
Re: Unified PIM
On Wed, 26 Sep 2007 18:49:43 +0100, <[EMAIL PROTECTED]> wrote: > >>I guess my only comment is that while I don't really care which >>interface people use on their phones, it seems like the data interfaces >>should be the same... If I open up qtopia phone edition and look at my >>contacts or maybe even edit them and then close it down and open up my >>OM interface and look at them, they should be the same. All edit are >>visible.. No double entry. > > Agreed, but I'd take it one step further. Given the neo has an internet > connection, why can't PIM data be stored on a web server and just cached > locally. Couldn't you then integrate that into desktop PIM applications > too? > I would prefer to not have a network dependency on PIM data. It might be a nice extra feature, but I would like to see the core data held on the phone supported by the different front-ends. I may want to switch frontends without resyncing all my data. It seems like LiPS might be a good start for this shared architecture. In the event of a "non-compliant" implementation, perhaps wrapper/abstraction scripts could be built to make it transparent to the end user? Regards, j. > Ok, so this isn't a new idea. :-) Evolution Data Server supports > integration to groupware backends, but from what I've seen, these are > enterprise-class groupware servers designed for corporations. I can't seem > to find anything designed for the consumer, an internet-accessible > groupware server I can sign up to and store my contacts in a single place. > > The problem is not local - I'd be surprised if Embedded EDS couldn't be > adapted to store it's data on a server and just use a cached dataset > locally. The problem is that this requires some server infrastructure and > so far I've yet to find something which will do it. Has anyone else seen > this done? > > > Cheers, > > Tom > > ___ > 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
Unified PIM
>I guess my only comment is that while I don't really care which >interface people use on their phones, it seems like the data interfaces >should be the same... If I open up qtopia phone edition and look at my >contacts or maybe even edit them and then close it down and open up my >OM interface and look at them, they should be the same. All edit are >visible.. No double entry. Agreed, but I'd take it one step further. Given the neo has an internet connection, why can't PIM data be stored on a web server and just cached locally. Couldn't you then integrate that into desktop PIM applications too? Ok, so this isn't a new idea. :-) Evolution Data Server supports integration to groupware backends, but from what I've seen, these are enterprise-class groupware servers designed for corporations. I can't seem to find anything designed for the consumer, an internet-accessible groupware server I can sign up to and store my contacts in a single place. The problem is not local - I'd be surprised if Embedded EDS couldn't be adapted to store it's data on a server and just use a cached dataset locally. The problem is that this requires some server infrastructure and so far I've yet to find something which will do it. Has anyone else seen this done? Cheers, Tom ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
