| 1 |
From: "Andreas Motl" <andreas.motl@ilo.de> |
| 2 |
To: <gpe@handhelds.org> |
| 3 |
Cc: <brentt@ill-logic.org>, |
| 4 |
<alan@lxorguk.ukuu.org.uk>, |
| 5 |
"su" <su@tunemedia.de>, |
| 6 |
<janosch@ultrajan.de> |
| 7 |
Subject: Re: SyncML |
| 8 |
Date: Sat, 22 Feb 2003 20:55:43 +0100 |
| 9 |
MIME-Version: 1.0 |
| 10 |
Content-Type: text/plain; |
| 11 |
charset="iso-8859-1" |
| 12 |
Content-Transfer-Encoding: 7bit |
| 13 |
X-Priority: 3 |
| 14 |
X-MSMail-Priority: Normal |
| 15 |
X-Mailer: Microsoft Outlook Express 5.50.4807.1700 |
| 16 |
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 |
| 17 |
|
| 18 |
Brent Theisen <brentt@ill-logic.org> wrote: |
| 19 |
> Quoting Alan Cox <alan@lxorguk.ukuu.org.uk>: |
| 20 |
> > > library/client/server/engine? The reference toolkit released by the |
| 21 |
> > > SyncML Initiative appears to be licensed |
| 22 |
> > >(http://www.syncml.org/php/licence.php3) |
| 23 |
> > > under a BSD style license. If this sort of license is unacceptable, |
| 24 |
> I have |
| 25 |
> > I had a dig. Its under a BSD license because you have to license |
| 26 |
> > patents to implement syncml and do so under as yet undecided terms. |
| 27 |
> That is unfortunate. The "SyncML Intellectual Property/Patent Issues" |
| 28 |
|
| 29 |
I did a short glimpse at syncml.org too and I am concerned about the |
| 30 |
patent issues as well. |
| 31 |
The "SyncML Initiative IPR Policy and Declarations" papers |
| 32 |
at http://www.syncml.org/syncml_ipr.html ff. mention two patents |
| 33 |
having the following titles: |
| 34 |
"Synchronization Process Negotiation for Computing Devices" |
| 35 |
"System and Methods for Synchronizing Information Among |
| 36 |
Disparate Datasets" |
| 37 |
|
| 38 |
[...] |
| 39 |
> So now what? I don't feel like implementing a brand new synchronization |
| 40 |
> protocol from scratch and then trying to get application developers to |
| 41 |
> adopt it. |
| 42 |
> However if this is what it will take to have a free synchronization |
| 43 |
> solution |
| 44 |
> for Linux then so be it, I'll try. |
| 45 |
> Anybody have an idea how we can solve the synchronization problem? |
| 46 |
|
| 47 |
We are currently trying to hack something which aims to address some (all) |
| 48 |
aspects of a synchronization process. I read the titles from the patent |
| 49 |
paper |
| 50 |
mentioned above *after* writing the core and believe it's exactly that what |
| 51 |
Starfish / syncml.org requires a license for - the "Synchronization Process |
| 52 |
Negotiation". |
| 53 |
|
| 54 |
Our thing is currently implemented using Perl and lives in |
| 55 |
the Data::Transfer::Sync namespace. It's not (yet) on CPAN! |
| 56 |
We will release the code under the GPL and/or Perl's Artistic License. |
| 57 |
|
| 58 |
Please let me know if you're interested to be informed in detail and/or |
| 59 |
about future changes/enhancements regarding synchronization with |
| 60 |
handheld devices. We just try to handle the "heavy stuff" first, that |
| 61 |
are odbms, rdbms, flat files and structured files (csv, xml and stuff). |
| 62 |
|
| 63 |
Already in the queue (and in first pre-alpha stage) is a program called |
| 64 |
'outlook2ldap' which tries to get address information off m$ outlook by |
| 65 |
synchronizing MAPI Contact objects against LDAP objects in a generic way |
| 66 |
handling all the important aspects needed (hierarchical containers, etc.). |
| 67 |
|
| 68 |
Any help - of course - is greatly appreciated, this got bigger than expected |
| 69 |
and the number of "device-handlers" that could be written is countless i |
| 70 |
believe. |
| 71 |
That's the main aim of that module: Making it possible to span such a |
| 72 |
synchronization process across *arbitrary* types of "storages". |
| 73 |
This is accomplished using the Data::Storage module (also not on CPAN yet) |
| 74 |
which "just adapts" other storage implementations available from there. |
| 75 |
Working (syncable=1) handlers are by now: DBI, MAPI, LDAP, Tangram. |
| 76 |
Directory, File, Files, XML are in preparation, please use rsync for the |
| 77 |
former three instead. Any ideas for other more important storage-handlers? |
| 78 |
|
| 79 |
Pushing the scope of available storage-/device-handlers, we had planned |
| 80 |
to address some PDAs and/or mobile phones soon. |
| 81 |
Also interesting would be an attempt to talk to iSync: |
| 82 |
please visit: http://www.confusticate.com/tech/isync/ |
| 83 |
|
| 84 |
Another nice feature is that the comparison algorithm itself can be |
| 85 |
replaced. At the time we have implemented a generic ident/checksum |
| 86 |
mechanism using md5 digests but an alternative to that would be |
| 87 |
a more user-friendly algorithm using ident/timestamp pairs. |
| 88 |
|
| 89 |
We don't have released anything, the code still lives in the cvs for now |
| 90 |
which |
| 91 |
can be visited at http://cvs.netfrag.org/nfo/perl/libs/Data/Transfer/Sync/ |
| 92 |
|
| 93 |
Please also look at the autogenerated documentation (not very much) at: |
| 94 |
http://netfrag.org/docs/topics/perl-libs/Data-Transfer-Sync.html |
| 95 |
http://netfrag.org/docs/topics/perl-libs/Data-Storage.html |
| 96 |
|
| 97 |
and maybe (remember it's pre-alpha and most probably broken): |
| 98 |
http://cvs.netfrag.org/nfo/perl/scripts/outlook2ldap |
| 99 |
|
| 100 |
|
| 101 |
|
| 102 |
regards, Andreas. |
| 103 |
|
| 104 |
p.s.: Do you see any possibility for me to look at some parts of the syncml- |
| 105 |
specification without breaking anything related to patent stuff and the GPL? |
| 106 |
I don't do this for now until i'm not completely sure about this, but |
| 107 |
of course i would like to adapt the interface specs to enable feeding |
| 108 |
of syncml documents to Data::Transfer::Sync.... Can you help? Please help! |
| 109 |
Otherwise we would make up a new DTD for this purpose although we |
| 110 |
currently do very well with 'sync.pl' together with mapping-metadata |
| 111 |
supplied |
| 112 |
by an additional Perl-module. (abstraction-level=medium) |
| 113 |
Please also direct me to other mailing lists if i'm completely out of scope |
| 114 |
here. |
| 115 |
|