« Return to Thread: Major re-design of mozilla-sync ?
Re: Major re-design of mozilla-sync ?
by Bjšoern Ricks-2
::
Rate this Message:
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
> 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...
>
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
« Return to Thread: Major re-design of mozilla-sync ?
| Free embeddable forum powered by Nabble | Forum Help |
