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