opensync-devel — The place to coordinate the development of OpenSync

Re: [Opensync-devel] multisync-gui-0.91 ported to 0.3x API

[<Juh...@ik...>]

On Thu, 28 May 2009, Daniel Gollub wrote:
>> names.  The resulting binary is right now called "opensync-gui".
>>
>> If anybody has a better idea for the program name, I am open
>> to all kinds of suggestions.  Maybe "osyncgui", or
>> "osynctool-gui", "gosynctool" or whatever.
>> At least eventually I would like to change
>> multisync.(c|h|glade) to a new name.
>
> I'm very name in giving naming - but why not keep the name "multisync"?
> "opensync-gui" might give a wroong impression that there is only one GUI :P
>
> And i wouldn't base it on "osynctool" .. since osynctool is just a quick and
> dirty opensync application as reference implementation for opensync based
> applictions. Not intended for end-users ... just for developers and advanced-
> testers...

How about calling it gsync, gosync, go-sync? Or gnome-sync?

I never really liked the kitchensync either. It tries to be funny 
but probably doesn't open up to majority of target audience.

But it might be a good thing give a tiny hint about the environment
where the tool is optimized imo. Nowdays those toolkits can be made
to look very alike and thus it might be easier.


Tuju

--
Varo hattup??si??autoilijoita.

Re: [Opensync-devel] Anyone remember the mininum required glib version?

[<Juh...@ik...>]

On Mon, 1 Jun 2009, Juha Tuomala wrote:
> Talking about years, RHEL 5 has 1:1.2.10-20.el5 and I'm afraid that's
> going to be around many years to come. RHEL5 is also the latest from that
> product so for many installations/cases, only option.
>
> Would it be hard to support 1.2.10 to allow server installations?

ARgh! Wrong pkg name:

Updating:
  glib2           x86_64        2.12.3-4.el5_3.1


mondays, bloody mondays. :) Thanks to Azeeem in irc.



Tuju


Varo hattup??si??autoilijoita.

Re: [Opensync-devel] Anyone remember the mininum required glib version?

[Juha T. <Juh...@ik...>]

On Monday 01 June 2009 01:39:22 Graham Cobb wrote:
> On Sunday 31 May 2009 19:22:42 Daniel Gollub wrote:
> > What was again the minimum version of glib we try to support?
> > Was it 2.12?
> 
> I believe the previous agreement was 2.12.  That certainly makes my life 
> easier as some of the platfiorms I support are still using that version.


> 
> In any case, if we do want to move on from 2.12 please choose a particular 
> version and stick with it for a couple of years -- it makes the porting job 
> easier.

Talking about years, RHEL 5 has 1:1.2.10-20.el5 and I'm afraid that's 
going to be around many years to come. RHEL5 is also the latest from that
product so for many installations/cases, only option.

Would it be hard to support 1.2.10 to allow server installations?


Tuju

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

Re: [Opensync-devel] Anyone remember the mininum required glib version?

[Graham C. <g+o...@co...>]

On Sunday 31 May 2009 19:22:42 Daniel Gollub wrote:
> What was again the minimum version of glib we try to support?
> Was it 2.12?

I believe the previous agreement was 2.12.  That certainly makes my life 
easier as some of the platfiorms I support are still using that version.

I guess we probably need to move on sometime, once we find considerable effort 
being needed to replace, avoid or reimplement things which are in later 
versions of glib.  If people feel we need to move on to a later version I 
guess now would be a good time to raise it.  Of course, that will mean that I 
will either need to drop support for the earlier platforms or reimplement or 
workround the new features.  

In any case, if we do want to move on from 2.12 please choose a particular 
version and stick with it for a couple of years -- it makes the porting job 
easier.

Graham

[Opensync-devel] Anyone remember the mininum required glib version?

[Daniel G. <go...@b1...>]

Hi,

just trying to get hands dirty again.

What was again the minimum version of glib we try to support?
Was it 2.12?

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: go...@b1...          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

[Opensync-devel] Multisync-gui revamp

[ajmctaggart <ajm...@gm...>]

Hello Opensync hackers!

I love your product, and thank you for bringing this to Linux, as it was one
of the last barriers to me switching completely to opensource.

I think, however, that the multisync-gui, could use some work...Things like
not being able to remove a member of a group, for example, and not having
the flexibility to detect one member of a group is unavailable and move on
with the sync.

Although I haven't generated any interest, this is where I am documenting my
progress in the Ubuntu forums...
http://ubuntuforums.org/showthread.php?t=1160470

I don't have any formal devel experience, but would be so grateful if I
could somehow be of service.

Data synchronization between devices is a huge stepping stone for the
maturity of Linux as a viable alternative to the big Apple and Microsoft.

I would really like to help jumpstart the multisync-gui to have a more
polished feel as well as make it more understandable for the end user...

Please point me in the right direction if this Opensync team has nothing to
do with the multisync-gui and moving forward on the development.

Thanks,
ajmctaggart

Re: [Opensync-devel] multisync-gui-0.91 ported to 0.3x API

[Daniel G. <go...@b1...>]

On Wednesday 20 May 2009 07:09:07 pm Juergen Leising wrote:
> Hello,
>
> I have adjusted the multisync-gui-0.91 code to the new API
> (0.3x/0.40), mostly copying the code from
> osynctool/tools/osynctool.c.  A few parts may still be
> oriented towards the old API, but as far as I can see
> the GUI should now work fully with the new API.  I have also
> introduced the error handling as usual in libopensync and
> modified this and that.
>
> The user can click at
> - add/remove groups
> - add/remove members of groups
> - edit a group configuration
> - edit a member configuration
> - which objtypes should be disabled,
> - which objtypes should be synchronized in a "slow-sync" manner
> - whether the merger feature should be enabled,
> - and the converter, and
> - whether or not he wants to accept the forecast summary (as in
>   osynctool.c)

Pretty cool!


> The configuration itself is nothing else but editing the XML file
> in a textview widget.

Actually frontends should never ever touch directly files in ~/.opensync/ 
directly instead use the OpenSync API - in this case OSyncPluginConfig API.

>
> There's is still quite a lot of output to text console, as soon
> as it comes to the synchronization.  Mabe in the future there
> could be added a widget dedicated to logging purposes.

That would be cool. Please also give us feedback for future OpenSync API 
design for proper error handling and stuff like that - to avoid the use simple 
printfs() like in multisync today....

>
> Currently I have not changed the file names and the function
> names.  The resulting binary is right now called "opensync-gui".
>
> If anybody has a better idea for the program name, I am open
> to all kinds of suggestions.  Maybe "osyncgui", or
> "osynctool-gui", "gosynctool" or whatever.
> At least eventually I would like to change
> multisync.(c|h|glade) to a new name.

I'm very name in giving naming - but why not keep the name "multisync"?
"opensync-gui" might give a wroong impression that there is only one GUI :P

And i wouldn't base it on "osynctool" .. since osynctool is just a quick and 
dirty opensync application as reference implementation for opensync based 
applictions. Not intended for end-users ... just for developers and advanced-
testers...

>
> BTW: Who were the original authors?  I would like to add
> a proper copyright notice to each file at the top, but
> not without mentioning them.

Daniel Friedrich ported it to the early 0.3x API.

Btw. where do you want to host the projects?
Currently we have the problem that opensync.org is maintained by one single 
person. And to avoid an increasing BUS-factor it might be a better idea to 
import your project to a different FOSS project hoster - instead of 
OpenSync.org. If you like i can send you a full copy of the original 
Subversion repository so you can keep the entire History of MultiSync.


Thanks for your contribution!

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: go...@b1...          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

[Opensync-devel] multisync-gui-0.91 ported to 0.3x API

[Juergen L. <jue...@gm...>]

Hello,

I have adjusted the multisync-gui-0.91 code to the new API
(0.3x/0.40), mostly copying the code from
osynctool/tools/osynctool.c.  A few parts may still be 
oriented towards the old API, but as far as I can see
the GUI should now work fully with the new API.  I have also
introduced the error handling as usual in libopensync and
modified this and that.

The user can click at 
- add/remove groups
- add/remove members of groups
- edit a group configuration
- edit a member configuration
- which objtypes should be disabled,
- which objtypes should be synchronized in a "slow-sync" manner
- whether the merger feature should be enabled,
- and the converter, and
- whether or not he wants to accept the forecast summary (as in
  osynctool.c)

The configuration itself is nothing else but editing the XML file
in a textview widget.

There's is still quite a lot of output to text console, as soon
as it comes to the synchronization.  Mabe in the future there
could be added a widget dedicated to logging purposes.

Currently I have not changed the file names and the function
names.  The resulting binary is right now called "opensync-gui".

If anybody has a better idea for the program name, I am open
to all kinds of suggestions.  Maybe "osyncgui", or
"osynctool-gui", "gosynctool" or whatever.  
At least eventually I would like to change 
multisync.(c|h|glade) to a new name.

BTW: Who were the original authors?  I would like to add
a proper copyright notice to each file at the top, but 
not without mentioning them.

Bye, bye

Juergen

Re: [Opensync-devel] Synthesis open source, provides data conversion (kind of)

[Patrick O. <pat...@gm...>]

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: +49-2232-2090-30
50321 Bruehl                              Fax: +49-2232-2090-29
Germany

[Opensync-devel] libsyncml 0.5.3

[Michael B. <mic...@cm...>]

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

libsyncml 0.5.3 release notes

Download: https://sourceforge.net/project/showfiles.php?group_id=25311

Major Changes
=============

  - Added a first implementation of the function smlDataSyncAbort.
    This function can be called if the synchronization must be abortedi
    (e.g. because of another external error like a full disk).
  - HTTP transport is now supported for old Solaris libsoup 2.2 packages

Minor Changes
=============

  - Added a missing SmlDevInf reference which causes a segmentation
    fault if a cached SmlDevInf object is used by OpenSync's SyncML
    plugin
  - Added support for the case that a client sends alert 200 and
    receives alert 200 but needs to update to a SLOW-SYNC alert 201
    because of an internal problem like wrong anchors (NOTE: This code
    is untested because I failed to simulate this until now.)
  - Fixed bugs related to Funambol/ScheduleWorld:
     - Fixed wrong vCal 1.0 device information.
       If the default format of a datastore is iCal 2.0
       then the content type for vCal 1.0 was wrong.
       Old (buggy): text/calendar 1.0
       New (correct): text/x-vcalendar 1.0
     - The Funambol server on scheduleworld.com returned error code 511.
       So the error code is supported now too.
     - The requested remote alert type is unknown and so let's signal
       this to the library user.
     - The getAlertTypeCallback should only be called once per
       data store.
     - Fixed return value of smlDataSyncClientSendAlert.
       If a slow-sync alert is initiated and the remote peer did not
       request it then the function must return false to trigger a
       status 508 (REFRESH_REQUIRED).
       If the requested alert type is not known then there is no need
       for a status and the function returns true. This can happen
       if the remote peer did not trigger the client via a SAN
       (e.g. OMA DS client over HTTP).
  - Added support for a separate mapping callback

Internal Changes
================

  - Added better cleanup code for the transport layer in
    smlDataSyncObjectUnref
  - Fixed several comments
  - Added some trace statements
  - Several fixes for libsoup
     - Added tests to validate libsoup
     - Several fixes for the asynchronous http client
     - Added timeout to asynchronous http client session
     - Fixed client callback for libsoup 2.2
     - Own thread and ctx for HTTP client
     - Added workaround for libsoup 2.2 http clients under Solaris
       (asynchronous http client support does not work under Solaris)
     - some cosmetical changes for http server code
       (traces, comments, assertions)
     - Added an internal function to run a function in a special thread.
       This feature is necessary because some libaries like libsoup are
       only designed for single-threaded applications. This means that
       every function must be called from the same thread. Otherwise
       there is no guarantee about the behaviour of the library.
     - libsoup_async respects now that SoupSessionAsync was designed for
       single-threaded applications.
  - Multi session fixes
     - Added multi session safe SAN callback
     - Fixed device information agent to be multi session safe.
       The old code only works if the manager manages exactly one
       session. If there is more than one session then the agent must
       take care about the different remote device capabilities.
     - Fixed remote device handling to be multi session safe.
       This is important if you ever implement long living processes or
       if you implement a client which wants to use its own session ID.
     - use new SAN callback which provides the session too which avoids
       race conditions (alternatively you can block the thread until the
       event SESSION_NEW will be dispatched)
  - Transport layer fixes:
     - Added code to test the transport layer context management
     - If a transport implementation has no public connect function
       then it cannot send a connect event.
     - smlTransportFinalize calls the finalize function of the transport
       implementations directly. The HTTP implementations depend on the
       correct thread because libsoup is single-threaded. This means
       that the worker thread must be available until all connections
       are closed (disconnected or finalized).
       Therefore the finalize function of a transport implementation
       must be called within the worker thread and the thread must be
       shut down after the finalize function was called.
  - Device Information fixes:
     - Added automatic localtime enforcement if the remote device sends
       a device information without UTC support
     - Ensure that the device information is always at the end of the
       message
     - If the alerts and the device information are in the same SyncML
       message then the alerts are dispatched faster. So it is necessary
       to check manually for an available remote device information.
  - Made smlQueueDetach of sml_queue.c thread safe
  - Made pendingMaps of objects/sml_ds_server.c thread safe
  - Added support for coverage analysis
  - Introduced internal mapping function.
    A change can now be freed after the status was received.

Fixed Tickets
=============

  - Fixed incorrect use of pthread_self (ticket #222).
    The patch was supplied by Henrik Kaare Poulsen.
  - Added missing @ONLY which reduces the memory usage from cmake
    (ticket #223).
  - Fixed wrong g_error usage (ticket #224).
    The patch was supplied by Henrik Kaare Poulsen.
  - Added default XML encoding explicitly because Sync4j requires it
    (ticket #225).
  - Abort more carefully
    (ticket #226 - does not affect 0.5.2 or earlier).
  - Added missing OBEX_TransportDisconnect in transport/obex_client.c
    (ticket #227). The original patch was supplied by Patrick Pfeifer.
  - Fixed some Windows/MinGW issues (ticket #228).
    The patch was supplied by Henrik Kaare Poulsen.
  - Fixed the target and source setting in change commands
    (ticket #229).
  - Google related fixes (ticket #230):
     - The HTTP client of DS API must support WBXML too.
       Google only supports WBXML today.
       (https://m.google.com/syncml is still a beta.)
     - Google has a wrong implementation of Alert Status.
       The Item Data is the Next Anchor.

                <Status>
                  <CmdID>5</CmdID>
                  <MsgRef>2</MsgRef>
                  <CmdRef>3</CmdRef>
                  <Cmd>Alert</Cmd>
                  <SourceRef>contacts</SourceRef>
                  <TargetRef>contacts</TargetRef>
                  <Data>200</Data>
                  <Item>
                    <Data><![CDATA[20090417T112101Z]]></Data>
                  </Item>
                </Status>

  - If an Item is deleted then it is not necessary to add a Data tag
    (ticket #232). The patch was supplied by Kwan hong Lee.
  - Sanitized UIDs (ticket #233).
  - Fixed DS API HTTP client inital allert which always sent a SLOW-SYNC
    alert (ticket #234).
  - Fixed skipping of Ext element (#235).
    The original patch was modified because the end of the new function
    could be reached without a return statement.
    The original patch was supplied by Kwan hong Lee.
  - Ticket #236 is a duplicate of ticket #232.
  - Fixed the handling of empty Data elements (ticket #237).
    The original patch was supplied by Kwan hong Lee.

A special thanks goes to:

  - Christian Hilgers (Solaris testing)
  - John Carr from  Codethink Ltd. (SchedueWorld.com testing)
  - Kwang hong Lee from  Windriver (fixed Sync4j bugs and
    Google testing)

Best regards

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoNd7oACgkQ2L0ZGCAwWqs/AACgyy8ZoQMJCNTElYhpQ8OJi7lx
6NYAoMsrgxD/G7WzD/6DIRL3gQUkPBWG
=piaP
-----END PGP SIGNATURE-----

Re: [Opensync-devel] Synthesis open source, provides data conversion (kind of)

[Michael B. <mic...@cm...>]

-----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.: +49 (0)30-2093 2482           ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704           Unter den Linden 6
mic...@cm...       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-----

Re: [Opensync-devel] Synthesis open source, provides data conversion (kind of)

[Jelle de J. <jel...@po...>]

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

Re: [Opensync-devel] Synthesis open source, provides data conversion (kind of)

[Patrick O. <pat...@gm...>]

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
--  
Pat...@gm...
http://www.estamos.de/

Re: [Opensync-devel] Implementing SyncML on a device

[Patrick O. <pat...@gm...>]

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
--  
Pat...@gm...
http://www.estamos.de/

Re: [Opensync-devel] Synthesis open source, provides data conversion (kind of)

[Patrick O. <pat...@gm...>]

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
--  
Pat...@gm...
http://www.estamos.de/

Re: [Opensync-devel] Implementing SyncML on a device

[Juha T. <Juh...@ik...>]

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.

Re: [Opensync-devel] Implementing SyncML on a device

[Daniel G. <go...@b1...>]

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: go...@b1...          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

Re: [Opensync-devel] Synthesis open source, provides data conversion (kind of)

[Juha T. <Juh...@ik...>]

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.

[Opensync-devel] Implementing SyncML on a device

[Graham C. <g+o...@co...>]

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

Re: [Opensync-devel] Synthesis open source, provides data conversion (kind of)

[Daniel G. <go...@b1...>]

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: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          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

[Opensync-devel] Synthesis open source, provides data conversion (kind of)

[Patrick O. <pat...@gm...>]

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
--  
Pat...@gm...
http://www.estamos.de/

Re: [Opensync-devel] [RFC] Plugin specifc capabilities II

[Graham C. <g+o...@co...>]

On Tuesday 12 May 2009 15:06:14 Graham Cobb wrote:
> One way to solve this problem is to have two separate capabilities files:
> one for filtering outbound updates, and a separate one for filtering
> inbound reports and merging.

I have just realised that this would be a very bad idea: the inbound filtering 
must always be a superset of the outbound (if the attribute was not sent to 
the device then clearly any value received from the device must be ignored). 

So, if the decision was to have two files they would have to be: one 
for "supported", the other for "untrusted" (and, by implication, anything not 
mentioned in either file would be "excluded").  It would not be an error to 
have the same attribute mentioned in both: "supported" would take priority.  
This is so that you could do things like have a phone number that just has a 
TYPE=HOME and one that just has TYPE=WORK supported while all other phone 
numbers would be untrusted (that is exactly what GPE's capabilities are).

The outbound filter code would remove attributes that are not mentioned in 
either file (i.e. "excluded").  The inbound filter code would remove 
attributes not mentioned in the "supported" file (i.e. excluded and 
untrusted).  The merger code would ignore any changes or additions or 
deletions if the attribute was not mentioned in the "supported" file. 
(Inbound filter and merger might be combined into one step -- I am not sure).

Graham

Re: [Opensync-devel] Schema error for vtodo20 from evolution

[Daniel G. <go...@b1...>]

On Wednesday 13 May 2009 10:26:15 am Ian Martin wrote:
> > In which component is the bug? :-)
>
> It is in the xmlformart-note schema
>
> the timezone element is commented out and there is no mention of any
> other of the Timezone* elements
>
>         <!-- FIXME: Timezone as Root node... like trunk? TOO MANY
> subnodes... <xsd:element maxOccurs="unbounded" minOccurs="0"
> name="Timezone" type="Timezone"/>
>         -->

Right, xmlformat-event and xmlformat-todo are still lacking XML-Schema 
definition for Timezone. Any volunteers? ;)

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: go...@b1...          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

Re: [Opensync-devel] Schema error for vtodo20 from evolution

[Ian M. <ian...@ca...>]

Of course I meant xmlformat-todo schema

oops!

2009/5/13 Ian Martin <ian...@ca...>:
>> In which component is the bug? :-)
> It is in the xmlformart-note schema
>
> the timezone element is commented out and there is no mention of any
> other of the Timezone* elements
>
>        <!-- FIXME: Timezone as Root node... like trunk? TOO MANY subnodes...
>        <xsd:element maxOccurs="unbounded" minOccurs="0"
> name="Timezone" type="Timezone"/>
>        -->
>
> Ian
>

Re: [Opensync-devel] Schema error for vtodo20 from evolution

[Ian M. <ian...@ca...>]

> In which component is the bug? :-)
It is in the xmlformart-note schema

the timezone element is commented out and there is no mention of any
other of the Timezone* elements

        <!-- FIXME: Timezone as Root node... like trunk? TOO MANY subnodes...
        <xsd:element maxOccurs="unbounded" minOccurs="0"
name="Timezone" type="Timezone"/>
        -->

Ian