Synthesis open source, provides data conversion (kind of)

[Patrick Ohly]

Hello!

You might have seen the news on LWN.net:
        http://lwn.net/Articles/333059/rss
        http://lwn.net/Articles/333157/rss

Synthesis, a commercial implementation of SyncML client and server
technology, is now open source (LGPL). SyncEvolution, originally my
spare time project, has been my full-time job at Intel since the
beginning of this year. Part of that work was the migration of
SyncEvolution to Synthesis and preparing this launch with them.

We couldn't talk about this publicly for a long time, much longer than I
had hoped, because of various legal issues and approvals that had to be
sorted out. However, we contacted Daniel and Michael in January and
discussed collaboration opportunities. My participation on the list
about data conversion aspects was a result of that.

However, I'm still not sure what OpenSync really is going to do
regarding data conversion and how much the source code in libsynthesis
will help. I also don't have time to participate in further discussions,
so I'm afraid all that can be offered at this time is the invitation to
look at the source code and provide patches if you need additional APIs.
Currently, data conversion is tied into a sync session context and using
it is not as easy as it could be (see sysync::DataConversion() for a
starting point).

Obviously, SyncEvolution+Synthesis cover some of the same aspects as
OpenSync (modular backends to access local data, could be turned into a
server). The way I see it, OpenSync and SyncEvolution+Synthesis are
moving towards the same goal from different directions: OpenSync
starting with the architecture and implementing more and more parts of
it, SyncEvolution+Synthesis starting from the code and adding features.

Because there is clearly urgent demand for it, we have to look at adding
the server mode to SyncEvolution+Synthesis and cannot wait for OpenSync
to fill that space. It's also less work for us to take that route.

--
Bye, Patrick Ohly
--  
Patrick.Ohly@...
http://www.estamos.de/



------------------------------------------------------------------------------
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

[Daniel Gollub-3]

On Thursday 14 May 2009 02:32:35 pm Patrick Ohly wrote:
> You might have seen the news on LWN.net:
>         http://lwn.net/Articles/333059/rss
>         http://lwn.net/Articles/333157/rss
>
> Synthesis, a commercial implementation of SyncML client and server
> technology, is now open source (LGPL). SyncEvolution, originally my
> spare time project, has been my full-time job at Intel since the
> beginning of this year. Part of that work was the migration of
> SyncEvolution to Synthesis and preparing this launch with them.

Congratulation for the release!

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.

And my impression from the Synthesis developers is that they really focus on a
interoperable SyncML stack - which is a very good thing!

>
> We couldn't talk about this publicly for a long time, much longer than I
> had hoped, because of various legal issues and approvals that had to be
> sorted out. However, we contacted Daniel and Michael in January and
> discussed collaboration opportunities. My participation on the list
> about data conversion aspects was a result of that.

Finally, i can talk again without tainting people with confidential stuff ;)
Btw. lots of people contacted my already regarding this announcement - so your
PR works pretty well. (Expect heise.de which stated SyncML as a standard for
synchronization PIM-only ;/)

>
> However, I'm still not sure what OpenSync really is going to do
> regarding data conversion and how much the source code in libsynthesis
> will help. I also don't have time to participate in further discussions,
> so I'm afraid all that can be offered at this time is the invitation to
> look at the source code and provide patches if you need additional APIs.
> Currently, data conversion is tied into a sync session context and using
> it is not as easy as it could be (see sysync::DataConversion() for a
> starting point).

Ok, thanks i'll have a look into once i have more time working on OpenSync
again. Got my git clone yesterday already ;)

JFYI, for all the other OpenSync developers. There were some discussion with
Synthesis Developers and they provided us with some information how they solve
the capabilities issues and how they do format conversion between the
different vFormats. Which sound very interesting.

Michael and me haven't seen the code before it got released under an Open
Source license, to avoid that we get tainted (and might harm our future
upstream development in libsyncml/OpenSync).

But there were some discussion to might isolate some vFormat-Handling code and
turn this into a libVxx. I hope there is still some interest in looking into
that.

(Maybe Lukas or Beat can use this opportunity to advertise your code - and why
it might be better then our XMLFormat-approach ;)


Yeah, and this is also the reason why i tried to make OpenSync more
independent of XMLFormat. I guess libsynthesis Format handling code already
deals pretty well with Timezones and all kind of Recurrence Rules which are
out in the wild.

Since, our xmlformat schema isn't final yet - and missing definition likes
Timezone. Maybe we should looking into libsynthesis (or libVxx) and evaluate
quickly if this codebase should be our primary common-format to deal with PIM
data. (libsynthesis also has some common-format, which they use when
converting from vcalendar to icalendar)

We still can provide format-plugins which convert between xmlformat and the
new libVxx common-format. So we don't break support for plugins which are
still directly rely on XMLFormat (but as i stated in the past they should try
to avoid direct dependency to XMLFormat - so we can easily replace XMLFormat
with something like libVxx)

[...]
> Because there is clearly urgent demand for it, we have to look at adding
> the server mode to SyncEvolution+Synthesis and cannot wait for OpenSync
> to fill that space. It's also less work for us to take that route.

Patrick, are you talking about SyncML Http Server or SyncML OBEX Server? Or
both? IIRC, last time we talked there was only the plan for HTTP.


Best Regards,
Daniel
 
--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: 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

[Graham Cobb-4]

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).

Graham

------------------------------------------------------------------------------
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

[Juha Tuomala-2]

On Thursday 14 May 2009 15:32:35 Patrick Ohly wrote:
>         http://lwn.net/Articles/333157/rss

Do you know what they do with it in Moblin?


Tuju

--
Better to have one, and not need it, than to need one and not have it.

------------------------------------------------------------------------------
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

[Daniel Gollub-3]

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: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: 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

[Juha Tuomala-2]

On Thursday 14 May 2009 17:30:43 Daniel Gollub wrote:
> 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.

I would recommend to look/contact into different openmoko activities on
this area, as they will face the exact same problem at some point.
Openmoko also has so many firmware projects ongoing that it might
be a good idea to do some group effort to collect all info same page
with implementation details, goals, contacts etc.


Tuju

--
Better to have one, and not need it, than to need one and not have it.

------------------------------------------------------------------------------
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

[Patrick Ohly]

On Thu, 2009-05-14 at 17:27 +0300, Juha Tuomala wrote:
> On Thursday 14 May 2009 15:32:35 Patrick Ohly wrote:
> >         http://lwn.net/Articles/333157/rss
>
> Do you know what they do with it in Moblin?

Yes, as I am the one doing it... ;-) Initially it will be used as a
SyncML client for HTTP servers. Features for future releases of Moblin
still need to be determined.

--
Bye, Patrick Ohly
--  
Patrick.Ohly@...
http://www.estamos.de/



------------------------------------------------------------------------------
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

[Patrick Ohly]

On Thu, 2009-05-14 at 14:45 +0100, Graham Cobb wrote:
> 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.

I hope I'm also excused for answering with a non-OpenSync pointer.

> 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).

This is exactly how SyncEvolution operates. Here's a tutorial how you
could extend SyncEvolution 0.8.1 to do what you want:
http://www.estamos.de/blog/2008/08/04/syncml-client-do-it-yourself-style/

The command line of SyncEvolution should work right away. Adding a GUI
would be more work, but is doable (the command line is just a thin
wrapper around code which can be compiled as library).

There also was a feature request for GPE (I just closed it, as part of
migrating the issues to the new tracker):
https://sourceforge.net/tracker/?func=detail&aid=2631819&group_id=146288&atid=764733

For 0.9 the API has been changed slightly, but the tutorial is mostly
still valid. More fundamental changes to use the Synthesis data
conversion in a better way are still pending:
https://bugzilla.moblin.org/show_bug.cgi?id=2417

I have submitted a technical article to LWN.net that serves as an
introduction to how SyncEvolution+Synthesis work. It should be published
shortly (the next few days). That might also give you some
ideas/insights.

--
Bye, Patrick Ohly
--  
Patrick.Ohly@...
http://www.estamos.de/



------------------------------------------------------------------------------
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

[Patrick Ohly]

On Thu, 2009-05-14 at 15:16 +0200, Daniel Gollub wrote:
> > Because there is clearly urgent demand for it, we have to look at adding
> > the server mode to SyncEvolution+Synthesis and cannot wait for OpenSync
> > to fill that space. It's also less work for us to take that route.
>
> Patrick, are you talking about SyncML Http Server or SyncML OBEX Server? Or
> both? IIRC, last time we talked there was only the plan for HTTP.

I don't think we had any plans for HTTP server then. We still don't have
a specific plan, but see the demand. The demand is primarily for OBEX
SyncML server, not so much client, but that is easier and thus something
we should look at first.

--
Bye, Patrick Ohly
--  
Patrick.Ohly@...
http://www.estamos.de/



------------------------------------------------------------------------------
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

[Jelle de Jong]

Patrick Ohly wrote:

> Hello!
>
> You might have seen the news on LWN.net:
>         http://lwn.net/Articles/333059/rss
>         http://lwn.net/Articles/333157/rss
>
> Synthesis, a commercial implementation of SyncML client and server
> technology, is now open source (LGPL). SyncEvolution, originally my
> spare time project, has been my full-time job at Intel since the
> beginning of this year. Part of that work was the migration of
> SyncEvolution to Synthesis and preparing this launch with them.
>
> We couldn't talk about this publicly for a long time, much longer than I
> had hoped, because of various legal issues and approvals that had to be
> sorted out. However, we contacted Daniel and Michael in January and
> discussed collaboration opportunities. My participation on the list
> about data conversion aspects was a result of that.
>
> However, I'm still not sure what OpenSync really is going to do
> regarding data conversion and how much the source code in libsynthesis
> will help. I also don't have time to participate in further discussions,
> so I'm afraid all that can be offered at this time is the invitation to
> look at the source code and provide patches if you need additional APIs.
> Currently, data conversion is tied into a sync session context and using
> it is not as easy as it could be (see sysync::DataConversion() for a
> starting point).
>
> Obviously, SyncEvolution+Synthesis cover some of the same aspects as
> OpenSync (modular backends to access local data, could be turned into a
> server). The way I see it, OpenSync and SyncEvolution+Synthesis are
> moving towards the same goal from different directions: OpenSync
> starting with the architecture and implementing more and more parts of
> it, SyncEvolution+Synthesis starting from the code and adding features.
>
> Because there is clearly urgent demand for it, we have to look at adding
> the server mode to SyncEvolution+Synthesis and cannot wait for OpenSync
> to fill that space. It's also less work for us to take that route.
>

I am wondering, all this talk about a server and client systems with
SyncML in this topic, how does this relates to the four bug reports
posted in the one bug report found here:
http://www.opensync.org/ticket/1073

Best regards,

Jelle de Jong

------------------------------------------------------------------------------
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

[Michael Bell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Ohly wrote:

> On Thu, 2009-05-14 at 15:16 +0200, Daniel Gollub wrote:
>>> Because there is clearly urgent demand for it, we have to look at adding
>>> the server mode to SyncEvolution+Synthesis and cannot wait for OpenSync
>>> to fill that space. It's also less work for us to take that route.
>> Patrick, are you talking about SyncML Http Server or SyncML OBEX Server? Or
>> both? IIRC, last time we talked there was only the plan for HTTP.
>
> I don't think we had any plans for HTTP server then. We still don't have
> a specific plan, but see the demand. The demand is primarily for OBEX
> SyncML server, not so much client, but that is easier and thus something
> we should look at first.

Do you mean OMA DS client over OBEX server transport or OMA DS server
over OBEX client transport?

BTW I think this creates the most confusion with the terms because
SyncML over OBEX transport uses opposite roles for DS and transport ;)

... and many thanks to Lukas and Beat.

Best regards

Michael
- --
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

Tel.: [phone]           ZE Computer- und Medienservice
Fax:  [phone]           Unter den Linden 6
michael.bell@...       D-10099 Berlin
___________________________________________________________________

PGP Fingerprint: 09E4 3D29 4156 2774 0F2C  C643 D8BD 1918 2030 5AAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoNNBoACgkQ2L0ZGCAwWqsehACgpB3gxAXUCt5Ca1TlDWYo0N4r
st0An0lVLSozGTWMM4iqteSrRpCPE/nf
=Xau5
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Patrick Ohly]

On Fri, 2009-05-15 at 11:21 +0200, Michael Bell wrote:

> Patrick Ohly wrote:
> > On Thu, 2009-05-14 at 15:16 +0200, Daniel Gollub wrote:
> >>> Because there is clearly urgent demand for it, we have to look at adding
> >>> the server mode to SyncEvolution+Synthesis and cannot wait for OpenSync
> >>> to fill that space. It's also less work for us to take that route.
> >> Patrick, are you talking about SyncML Http Server or SyncML OBEX Server? Or
> >> both? IIRC, last time we talked there was only the plan for HTTP.
> >
> > I don't think we had any plans for HTTP server then. We still don't have
> > a specific plan, but see the demand. The demand is primarily for OBEX
> > SyncML server, not so much client, but that is easier and thus something
> > we should look at first.
>
> Do you mean OMA DS client over OBEX server transport or OMA DS server
> over OBEX client transport?
>
> BTW I think this creates the most confusion with the terms because
> SyncML over OBEX transport uses opposite roles for DS and transport ;)

I know, this is really confusing. So when I said "OBEX SyncML server", I
meant "SyncML server" with OBEX binding, which happens to be implemented
as an OBEX client ;-)

--
Best Regards

Patrick Ohly
Senior Software Engineer

Intel GmbH
Open Source Technology Center              
Hermuelheimer Strasse 8a                  Phone: [phone]
50321 Bruehl                              Fax: [phone]
Germany


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel