On Thursday 14 May 2009 03:45:05 pm Graham Cobb wrote:
> On Thursday 14 May 2009 14:16:03 Daniel Gollub wrote:
> > I'm quite sure this a big win for the Open Source Community and SyncML
> > driven technology in general. I hope this helps that SyncML turns into a
> > primary-used Synchronization standard and avoids that more and more
> > reinvented-wheel- synchronization-protocols (and especially without open
> > standards) pop up.
>
> I know this isn't really an OpenSync question so apologies for raising it
> on this list, but Daniel's point reminded me of something I had been
> thinking about.
>
> How easy would it be for me to add SyncML support to GPE and get rid of the
> GPE plugin? At the moment I have my own simple protocol between the GPE
> plugin and gpesyncd (the agent that runs in the GPE environment) -- pretty
> much all it does is pass VFormat objects backwards and forwards (the back
> end GPE code knows how to import and export VFormat data).
>
> Is there some sort of library and/or example agent I could use to easily
> support SyncML? I could even do with a pointer to a simple SyncML
> tutorial! I don't even know the correct terminology to use (I have always
> found "client" and "server" confusing in SyncML).
Looks like there are several good options as SyncML stack ;)
Regarding the client/server terminology - you can have following SyncML
combination with HTTP and OBEX:
SyncML Client as OBEX Server
SyncML Client as HTTP Server
SyncML Client as OBEX Client
SyncML Client as HTTP Client
SyncML Server as OBEX Server
SyncML Server as HTTP Server
SyncML Server as OBEX Client
SyncML Server as HTTP Client
(Some of this combination doesn't exist in real life - but i guess they are
possible in theory)
The major difference between SyncML Server and SyncML Client ist that the
Server does the "conflict"-handling and the mapping. Maybe in your case this
would be (for example) OpenSync running on your PC if you want to sync your
Desktop with your device.
If you want to use your device to synchronize with a mobile - you need to act
as Server. Mobiles usually act as SyncML Client.
Now there is also the Transport-Role and the two supported Transports OBEX and
HTTP.
Most mobile phones, which synchronize via USB or Bluetooth - but not establish
an IP connection - use today OBEX as transport. I guess the reason is that
only the SyncML OBEX Transport is able that the SyncML Server (e.g. your PC)
to trigger a Synchronization. Very common with SyncML HTTP is that mobile
phones (SyncML Client) trigger the Synchronization with a SyncML
service/service.
So with SyncML 1.2, if you want to trigger the synchronization from your PC
you might want to go with OBEX Transport. So your PC would act as SyncML
Server OBEX ???? - and your device SyncML Client OBEX ???
Which OBEX Transport Role? I would recommend that your device acts as OBEX
Server. Why?
1. you can directly start chatting OBEX to trigger the Sync
2. maybe one day you want to provide obex-ftp or obex-push as well
3. OpenSync has already a plugin for the SyncML Server side called:
"syncml-obex-client"
(actually we would need to call it: syncml-server-obex-client)
Not quite sure whats libsynthesis plan for OBEX Transport. But i guess today
libsyncml is the best open SyncML OBEX on this planet ;)
Michael writes unittests to test libsyncml which setup OBEX Server and OBEX
Client connection and do SyncML chatting.
So maybe you start looking into "syncml-ds-tool" as a reference
implementation. But i'm sure Michael can give your more detail starting tipps
how to implement a libsyncml based SyncML-Client-OBEX-Server.
If you have an IP connection and you want to synchronize with a SyncML Server
HTTP Server (like Scheduleworld or moblical(?)) you might want to go with
SyncEvolution directly.
(Please don't implement ActiveSync - there is for some reason some ActiveSync
implementation-hype .. i really wonder why ;)
Best Regards,
Daniel
--
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner
FOSS Developer Unternehmenssitz: Vohburg
B1 Systems GmbH Amtsgericht: Ingolstadt
Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537
EMail:
gollub@... http://www.b1-systems.deAdresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled.
http://p.sf.net/sfu/kodak-com_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel