Major re-design of mozilla-sync ?

Dear all,

I am considering a major redesign of the mozilla-sync plugin, and I
would appreciate your comments on this...

Today mozilla-sync works by initializing the Mozilla Cross-platform
library (XPCOM) and using XPCOM functions to access addressbook and
calendar data.

The blueZync frontend/GUI is a Thunderbird/Sunbird plugin, which
perpares OpenSync groups, and simply spawns a process which calls
OpenSync (much like osynctool). It also contains the "glue" between the
Thunderbird/Sunbird GUI and OpenSync.

However, there are several problems with this approach:

(A) The Mozilla xpcom functions are NOT thread-safe and should not be
called from different processes at the same time. If the user starts
synchronizing from within Thunderbird/Sunbird (usual case) we will have
two processing accessing the calendar/addressbook at the same time. And
if the user has Thunderbird/Sunbird open and synchronizes with osynctool
the same will happen.

(B) mozilla-sync depends on both OpenSync and Mozilla. On Windows,
OpenSync compiles with GNU gcc, whereas Mozilla compiles with Microsoft
Visual Studio. As Mozilla XPCOM is a C++ library, it will only link with
libraries compiled with the same compiler (family). Compiling Mozilla
from source on Windows with Visual Studio works well; compiling with GNU
gcc is very difficult go get to work, and most users would have the
default Mozilla applications, which are compiled with Visual Studio. So
we have to compile OpenSync with the Visual Studio compiler, and at
least with Visual Studio 2003 this does not work (at least because of
the way it handles macro definitions). And in any case I don't like to
rely on a closed-source, non-free development suite.

This boils down to: We need a different approach.

This approach would have all calendar/addressbook access done inside the
Mozilla process, in JavaScript.
Bear in mind, that JavaScript is single-threaded...

So, I see the following solutions:

1) Implement most of the OpenSync plugin functionality like any OpenSync
plugin, but contact a running Thunderbird/Sunbird to grab
calendar/addressbook data. This is difficult, as Mozilla has no IPC
(except to issue a HTTP request).

2) Implement the OpenSync plugin functionality as a http server. The
Mozilla JavaScript would then be in control of the sync and issue HTTP
requests to the server. I think this would require a lot of work, and be
difficult to get to work reliably.

3) Implement a SyncML HTTP server or client in Thunderbird+Sunbird
Javascript. At the moment, this is my preferred solution. (Tobias
Svensson has already implemented a SyncML client for Thunderbird, but
the project does not seem to be maintained.
http://www.topologilinux.com/syncml/)

Comments?

/Henrik

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel