/[cvs]/joko/doc/topics/gde.txt
ViewVC logotype

Contents of /joko/doc/topics/gde.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations)
Mon Feb 24 18:21:25 2003 UTC (21 years, 9 months ago) by joko
Branch: MAIN
CVS Tags: HEAD
File MIME type: text/plain
updated

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

MailToCvsAdmin">MailToCvsAdmin
ViewVC Help
Powered by ViewVC 1.1.26 RSS 2.0 feed