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