Major re-design of mozilla-sync ?

[Henrik /KaarPoSoft]

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

[Friedrich Beckmann]

Hi,

i tried the tsync client that you mentioned below by getting
a mobical account. I tried that with my Nokia2760 and I could
upload the address book from my phone to mobical.

Then I tried to download the address book from mobical to
thunderbird. I could fetch many addresses but for some
addresses not all phone numbers got transfered. Also while
the transfer is ongoing, thunderbird is not responding anymore.
A progress bar came up but that was somewhat frozen. Instead a
warning popped up saying that some script is not responding.
It all ended with some error in the javascript code. But many
addresses got transfered!

So regarding the last release date of 2006 I was quite impressed
that it worked that good.

 From my point of view the syncml client would itself have the
value that you can sync against syncml servers right away - like
I tried...

It would have the benefit that it can be done in javascript and
is portable right away. But the responsiveness is really ugly and
I am not too sure if/how that can be solved.

I have not tried to include the opensync library in thunderbird
so far. My understanding is that you can compile the library
with mingw and use it lateron with MSVC by producing the
appropriate import libraries as described here:
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

That would allow to use MSVC to compile thunderbird while
use MinGW to compile opensync, no?

I am not too sure if I understand the difference between
your option 2 and 3. Using the tsync as syncml client would
require to have opensync running as syncml server, no?
That will use http as transport, no? Could you maybe explain
the difference between 2 and 3?

Regards

Friedrich

Henrik /KaarPoSoft schrieb:

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

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

[Juha Tuomala-2]

On Tuesday 21 April 2009 17:54:33 Henrik /KaarPoSoft wrote:
> However, there are several problems with this approach:

> Comments?

How about asking this from mozilla folks? For me it sounds
like you're trying to get around an implementation problem and
it would not needed if they would have addressed their storage
and access to it other way.

I'm sure they find proper sync solution important for whole
product suite and would be willing to listen you and if needed,
change things. Perhaps they could steal some core design from
evolution dataserver.


Tuju

--
Varo hattupäisiä autoilijoita.

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

[Patrick Ohly]

Hello!

I agree that compiling C/C++ code has issues, but I'm not sure whether
it can be avoided. Just in case that you decide to continue with this
approach, let me point out that there is already a C++ based SyncML
client for Mozilla:
https://mozilla-plugin.forge.funambol.org/

--
Bye, Patrick Ohly
--  
Patrick.Ohly@...
http://www.estamos.de/



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

[Bjšoern Ricks-2]

Hi Henrik

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

Are events in Mozilla generated in synchronous manner? What about
event's from external/extension xpcom libraries? Haven't thought about
this until now. So I am very interested in how Mozilla handles threads
and events internally.
> 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).
>  
Isn't this approach similar to the current implementation? What about
the changes in Thunderbird 3.0? Will there be shared libs to access the
necessary functions via xpcom (regarding your thread at
http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/1a09af15cf27ae61)
> 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.
>  
I am not sure if I understand this correctly. The JavaScript code inside
Mozilla should make http requests to an opensync plugin which is acting
as a http server? I guess that this approach would be (nearly) impossible.
> 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/)
>  
That's the solution I like most too. Because it would allow to sync all
kind of data from Thunderbird/Mozilla. Not only the address book and
calendars. Currently I am missing a feature to sync my RSS folders ;-)


--
/Bjoern Ricks

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

[davidkw]

Henrik /KaarPoSoft wrote:

Dear all,

I am considering a major redesign of the mozilla-sync plugin, and I
would appreciate your comments on this...
...
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/)

Hi Henrik,

I quite like the idea of javascript, based on the KISS principle: Keep It Simple Stupid. I work implementing Oracle's new collaborative software called Beehive which is SyncML compatible: I use it to sync my Nokia phone for calendar and contacts. I've just tried Tobias' Tsync which seems to have correctly uploaded my TBird addressbook to the server, but no download. If you plan to work on this I'd be glad to help testing with Beehive (I'm no good as a developper I'm afraid...). Such an extension would be yet another argument for many people to ditch a well known proprietary email client!

Regards

David