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

[Patrick O. <pat...@gm...>]

On Mon, 2009-10-19 at 22:44 +0100, Paul Eggleton wrote:
> 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,

At the risk of repeating myself: where is the merge and conflict
handling engine which takes device capabilities into account? I'm not
even sure whether the APIs are in place for it. The last time this came
up, it wasn't clear whether capabilities were format independent or tied
to a specific data format. Even if the APIs are defined and somewhat
documented, unless there's an implementation which does everything which
is needed, I consider the API experimental.

You've mentioned SyncEvolution below; I'm using that as an excuse to say
a bit more about it ;-)

> > - OpenSync has invented it's own protocol - though SyncML is also
> > supported via plugin.
> 
> I'm not sure what you mean.

I bet Henrik means the dataflow protocol. It handles exchanging change
information and item data, just like SyncML. It may be more flexible,
but it also has issues with timeouts (solved?) and handling "unusual"
batches of changes (SyncML, solved by removing timeouts?!). This is just
from reading what was said here on the list, my apologies if I
misunderstood the issues.

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

Not quite. With the SyncEvlution backend API, which is about as
difficult (or easy) as the datasource API in OpenSync, it is very easy
to write a SyncML client using SyncEvolution. The device or datasource
doesn't have to support SyncML. Once that is done and we have the
"personal SyncML server" working 1.0 (it already runs, but there are
also many known TODOs), then synchronization between that non-SyncML
datasource, the core databases and other datasources works.

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

Do you have a specific system in mind? In which way is it more complex
than SyncML such that it cannot be mapped to SyncML? Can it be mapped to
OpenSync semantics?

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

The good news perhaps (depending on how you decide to proceed) in this
discussion is that it doesn't have to be written from scratch. The
Synthesis engine exists, it solves all of the hard problems that are
missing in OpenSync [1].

The discussions earlier this year on the list and also in private with
Daniel + Michael (private because it was still confidential und
uncertain then whether Synthesis would go open source) was an attempt to
find out how that engine could have been used in OpenSync. I'm afraid
that this is quite a bit of work and not something that I could take on
and meet our goals (working SyncML client in Moblin 2.0). It's far
easier to take the existing Synthesis framework and build something
around it instead of shoehorning it into a different system, in
particular one where the key aspects (data handling) are unclear (to
me!).

I don't want to distract from the discussion around OpenSync, but if it
helps: I can promise that if there is an interest in switching the core
engine, then I'll do all I can to help salvage the parts which IMHO are
working (datasource plugins and the community which produced them) by
integrating them into SyncEvolution and making sure that they get
released. I haven't talked about this with my managers at Intel, but I'm
confident that they will support this, even if it means shifting some of
our schedule around.

[1] http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard

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