Re: [Opensync-devel] Getting things back on track

[Henrik /K. <kaa...@us...>]

Dear all,

Three or four years ago I developed a piece of software - NokSync - to 
sync Mozilla to a Nokia mobile phone.
See http://www.kaarposoft.dk/noksync/
Users seemed to be quite happy with it! And so was I...
NokSync works only on windows and only with older versions of Nokia PC 
Suite.

So, two years ago I switched to Linux, and wanted to do the same.
OpenSync seemed like the perfect platform for this.
However, now - after two years - it still does not work...

OpenSync 0.40 seems just around the corner, but so it did 6 months ago, 
and 12 months ago.

So, I am taking a step back and asking myself:
What are we trying to accomplish?

----- oOo -----

My own "personal" goal is: From my Linux or Windows desktop, to sync 
Mozilla Thunderbird and Sunbird to any SyncML capable phone.
Or, I guess more generally, to allow an end user to:
Synchronize "any contact/calendar source" with any other such source(s).
Where a source could be a local device (mobile phone, PDA, etc), a local 
application (Thunderbird, Outlook, KDE Pim, Evolution, etc), or a remote 
application (GMail, etc).

Use Case:
I have a mobile phone, a GMail account, and a local Thunderbird 
installation. I want to keep those three in sync from my Linux or 
Windows desktop.

So, I ask myself: How can/should this be done?
What we need is:
1) A desktop application.
2) A protocol between the desktop app and each data source.
3) Capabilities in each data source to use the protocol.

Where (1) should maybe be extended to:
1a) Several desktop applications (KDE, GTK, Windows, ...)
1b) Plugins for existing local applications (KDE Pim, Thunderbird, ...) 
to provide an application-centric GUI
1c) A library for (1a) and (1b) to use

As for (2) - a protocol - I really only see one "standard" choice out 
there: SyncML.
So we could invent our own protocol (like in OpenSync) or stick to the 
"standard" SyncML.

Regarding (3):
Most mobile phones have SyncML capabilities.
Plugins exists for many applications to provide SyncML in one way or 
another - not all directly suited to our needs, but most could be used 
as building stones.

----- oOo -----

Funambol seems to be a successful solution to sync issues, and has 
native support or plugins for a multitude of devices and applications.
However, it deviates from "my objective" in one important way: it is 
based on a central server.
Devices / applications sync towards this central server.
You could implement such a sever on your own desktop (Funambol provides 
open sources for this), but sync would still be initiated by a 
device/application and sync towards one central database.

----- oOo -----

OpenSync - if we ever deliver - would implement most of "my objectives", 
but:
- will we ever deliver?
- OpenSync has invented it's own protocol - though SyncML is also 
supported via plugin.
- OpenSync will require custom-made plugins for each data source to be 
supported.
- As witnessed by this mailing list, it seems that the OpenSync design 
is so complicated and poorly documented, that willing contributors are 
scared off.

----- oOo -----

So, here is a proposal:

Let's create a new project (called newSyncML? OpenSyncML? ???)
In this project, let's develop
A) a library for SyncML synchronization
B) one or more desktop applications using (A)
C) one or more plugins for existing applications - using (A)
D) a library helping to develop a SyncML server for "any data-source"
E) plugins / applications / whatever for different data-sources to act 
as SyncML servers - possibly using (D)

(A) would mainly have to deal with data comparison and anchors and 
GUID/LUID mappings.

----- oOo -----

Daniel and others, I am sorry, but this is really a call for "Don't 
throw good money after bad".
I am considering whether OpenSync is really the way to go for "my 
objectives", and more and more it looks like a no...


What do you all think about this proposal?

/Henrik

Martin Owens wrote:
> Hey Paul,
>
> Perhaps the problem is that the opensync project has attempted to solve
> too many problems in the same framework?
>
>  * Data Access
>  * Data Formating
>  * Synchronisation Logic
>
> It would have probably have been a better idea if each of those problems
> had been solved separately but in ways that made them core components to
> the operating systems and perhaps in ways that made their extension
> trivial.
>
> Ubuntu still does not ship with any synchronisation functionality
> because compounding all problems into one project has made the entire
> thing a huge non-trivial problem.
>
> But perhaps it's too late now, I'm resined to the fact that I will never
> have good sync support and that every front end app will have poorly
> written data access, formating and syncing and the OS will never have
> anything definitive.
>
> Why are we trying to solve these problems? was it wise to write
> something that needed to be rewritten several times, whilst supporting
> obsolete versions and fracturing development effort and sapping the will
> of extension developers?
>
> I question the choices made in this project.
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
>