Re: SyncML

Brent Theisen <brentt_at_ill-logic.org> wrote:
> Quoting Alan Cox <alan_at_lxorguk.ukuu.org.uk>:
> > > library/client/server/engine? The reference toolkit released by the
> > > SyncML Initiative appears to be licensed
> > >(http://www.syncml.org/php/licence.php3)
> > > under a BSD style license. If this sort of license is unacceptable,
> I have
> > I had a dig. Its under a BSD license because you have to license
> > patents to implement syncml and do so under as yet undecided terms.
> That is unfortunate. The "SyncML Intellectual Property/Patent Issues"

I did a short glimpse at syncml.org too and I am concerned about the
patent issues as well.
The "SyncML Initiative IPR Policy and Declarations" papers
at http://www.syncml.org/syncml_ipr.html ff. mention two patents
having the following titles:
    "Synchronization Process Negotiation for Computing Devices"
    "System and Methods for Synchronizing Information Among
        Disparate Datasets"

[...]
> So now what? I don't feel like implementing a brand new synchronization
> protocol from scratch and then trying to get application developers to
> adopt it.
> However if this is what it will take to have a free synchronization
> solution
> for Linux then so be it, I'll try.
> Anybody have an idea how we can solve the synchronization problem?

We are currently trying to hack something which aims to address some (all)
aspects of a synchronization process. I read the titles from the patent
paper
mentioned above *after* writing the core and believe it's exactly that what
Starfish / syncml.org requires a license for - the "Synchronization Process
Negotiation".

Our thing is currently implemented using Perl and lives in
the Data::Transfer::Sync namespace. It's not (yet) on CPAN!
We will release the code under the GPL and/or Perl's Artistic License.

Please let me know if you're interested to be informed in detail and/or
about future changes/enhancements regarding synchronization with
handheld devices. We just try to handle the "heavy stuff" first, that
are odbms, rdbms, flat files and structured files (csv, xml and stuff).

Already in the queue (and in first pre-alpha stage) is a program called
'outlook2ldap' which tries to get address information off m$ outlook by
synchronizing MAPI Contact objects against LDAP objects in a generic way
handling all the important aspects needed (hierarchical containers, etc.).

Any help - of course - is greatly appreciated, this got bigger than expected
and the number of "device-handlers" that could be written is countless i
believe.
That's the main aim of that module: Making it possible to span such a
synchronization process across *arbitrary* types of "storages".
This is accomplished using the Data::Storage module (also not on CPAN yet)
which "just adapts" other storage implementations available from there.
Working (syncable=1) handlers are by now: DBI, MAPI, LDAP, Tangram.
Directory, File, Files, XML are in preparation, please use rsync for the
former three instead. Any ideas for other more important storage-handlers?

Pushing the scope of available storage-/device-handlers, we had planned
to address some PDAs and/or mobile phones soon.
Also interesting would be an attempt to talk to iSync:
    please visit: http://www.confusticate.com/tech/isync/

Another nice feature is that the comparison algorithm itself can be
replaced. At the time we have implemented a generic ident/checksum
mechanism using md5 digests but an alternative to that would be
a more user-friendly algorithm using ident/timestamp pairs.

We don't have released anything, the code still lives in the cvs for now
which
can be visited at http://cvs.netfrag.org/nfo/perl/libs/Data/Transfer/Sync/

Please also look at the autogenerated documentation (not very much) at:
    http://netfrag.org/docs/topics/perl-libs/Data-Transfer-Sync.html
    http://netfrag.org/docs/topics/perl-libs/Data-Storage.html

and maybe (remember it's pre-alpha and most probably broken):
    http://cvs.netfrag.org/nfo/perl/scripts/outlook2ldap

regards, Andreas.

p.s.: Do you see any possibility for me to look at some parts of the syncml-
specification without breaking anything related to patent stuff and the GPL?
I don't do this for now until i'm not completely sure about this, but
of course i would like to adapt the interface specs to enable feeding
of syncml documents to Data::Transfer::Sync.... Can you help? Please help!
Otherwise we would make up a new DTD for this purpose although we
currently do very well with 'sync.pl' together with mapping-metadata
supplied
by an additional Perl-module. (abstraction-level=medium)
Please also direct me to other mailing lists if i'm completely out of scope
here.
Received on Sun Feb 23 2003 - 19:43:01 EST