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

[Paul E. <blu...@bl...>]

On Mon, 19 Oct 2009, Henrik /KaarPoSoft wrote:
> OpenSync 0.40 seems just around the corner, but so it did 6 months ago,
> and 12 months ago.

Well, it gets further and further away mostly for two reasons: (a) various 
people having less time to work on it (the problem we are trying to solve); 
and (b) adding extra features. The latter hasn't been so much of a problem 
recently but during 0.40 lifecycle a *lot* of new features were added. IMHO we 
tried to produce something perfect for the 0.40 version, and so bit off more 
than we were able to chew. I get the impression that most of the hard 
implementation work is done though, and I think we've now reached a stage 
where we should not be considering (or even need to consider) adding anything 
major to the API.
 
> 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).

I like OpenSync's overall goal - to provide the framework that allows 
synchronisation of PIM data from anything to anything. Nobody else in the open 
source arena has ever done this before*. Heck, few high-profile products in the 
commercial world can do this, as far as I know. Nokia bought IntelliSync some 
years ago but I've heard little about it since then, and frankly I doubt it is 
capable of all the things OpenSync is designed to be. It's ambitious, sure, 
but given enough resources I don't believe it's impossible.

(* - well, Conduit is equally ambitious, and at the outset there was hope that 
they would be able to collaborate with us; I know John Carr really tried hard 
on this one, but ultimately they weren't sure how to integrate OpenSync into 
their system and we weren't ready ourselves. Last I heard (over a year ago) 
they were still discussing how to handle some of the classic synchronisation 
problems with PIM data (like conflict resolution) that OpenSync at least in 
design had already solved. Anyway let's not dwell on past events - let's focus 
on the present.)

> OpenSync - if we ever deliver - would implement most of "my objectives",
> but:
> - will we ever deliver?

That is a good question. I think we can, but it can't be done just by two or 
three people. We need to widen the participation.

> - OpenSync has invented it's own protocol - though SyncML is also
> supported via plugin.

I'm not sure what you mean. OpenSync's original design did revolve around the 
internal XML format though. This is now semi-deprecated, although I have to 
admit I am not clear on the details of how that has/will happen - that is 
something to discuss/document definitely. FWIW xmlformat is largely an XML 
representation of the vFormats anyway, so it's not particularly unusual.

> - OpenSync will require custom-made plugins for each data source to be
> supported.

That is true. What is also true is the barrier to creating a new plugin is 
quite high - there is a lot to implement for a plugin writer and it has to be 
done correctly or things will go wrong during sync. Honestly though with the 
variation of different targets to sync with I'm not sure there is a more 
effective solution.

It was supposed to be possible to write plugins in Python at one stage, I 
personally do not know the status of this - does it still work?

> Let's create a new project (called newSyncML? OpenSyncML? ???)

The solution you propose is (AFAICT) the approach Patrick & co. have been 
taking with SyncEvolution. It looks to be working well for them and I 
certainly wish them all the best; for modern devices SyncML is becoming 
universal.

However, the targets I am considering (and AFAIK the one which you mostly work 
on, Mozilla) can't rely solely on SyncML however. That is where a lot of the 
problems lie in my opinion. Reducing this down to a simple translation layer 
between SyncML and any other synchronisation system I believe may be 
oversimplifying - I think there's a lot more work there than you may be 
thinking of.

> Daniel and others, I am sorry, but this is really a call for "Don't
> throw good money after bad".

Personally I don't think we've reached that stage - there is also the saying 
"don't throw the baby out with the bath water". I truly believe the concepts 
in the design behind OpenSync are solid. Some of the implementation and 
details leave something to be desired; but starting completely from scratch 
will simply mean rewriting the same things again, perhaps just in a different 
order. I don't see much benefit in that, and it will certainly take a lot more 
time.

Cheers,
Paul