Re: [Opensync-devel] Ubuntu UDS-Boston, Syncing solutions

[John Carr <john carr unrouted co uk>]

So many e-mails to reply to!

On Thu, 2007-11-01 at 14:31 +0100, Daniel Gollub wrote:
> On Thursday 01 November 2007 02:29:10 John Stowers wrote:
> > On 11/1/07, John Carr <john carr unrouted co uk> wrote:
> > > I think for now its more sane (and least effort) for us just to use the
> > > opensync plugin... If I can get my P900 all set up then theres no reason
> > > why this wouldnt be viable. And write a HAL callout in C or Vala to poke
> > > and probe for capabilities.
> >
> > I think as a first pass, and as john mentioned, we are very close to
> > hosting opensync plugins in conduit.
> 
> I really have certain doubts that you're just hijacking the OpenSync plugins 
> and write your own synchronization logic. So the whole complexity of the 
> OpenSync engine would be just duplicated ...

As i've stated repeatedly. This is phase 1. I openly admit that opensync
is better at PIM syncing. That is why I started looking at opensync
integration. I'm one of the SynCE devs so I have enough experience to
directly hook up Conduit and SynCE without putting opensync in the
middle. So please don't accuse me of anything dodgey!

Conduit hasn't made its opensync policy clear enough, *I personally*
want good integration between our two projects. Otherwise I would have
SynceModule and not OpenSyncModule sat in our trunk right now.

> Actually this was the basic idea of OpenSync to avoid such thing again.
> To reimplement just another synchronization-something-application which has a 
> half implemented synchronization logic. So conflict handing, mappings, 
> slow-syncing, comparing of changes, format conversation, objtype handling and 
> so on get implemented once again..

Conduit started out to make sync "just work". We want to build a high
level of integration with the desktop. The sync we built in was just a
means to and end, as the python bindings for opensync at the time werent
really there (and we /did/ send patches...). OpenSyncModule has proven
itself so that situation must have changed and hence why i'm trying to
move forward on unification.

> Sure, Conduit has some fancy stuff like syncing something else then PIM 
> data... but OpenSync is currently specialized in syncing content-specific 
> data which could be in different formats, like PIM. But this might be change 
> in future...

We've done a lot of integration work which we can't just abandon.
OpenSyncModule gets us there without breaking thinks like Files, Tomboy
notes, and gconf keys that get automatically sync'd. So when I create a
tomboy note it will just be synced wherever. It means we can keep our
HAL integration for iPods and N800 and extend it to cover PDAs and
phones.

We can't afford to lose this integration because if we do, we lose.
Right now there are a lot of projects that want sync. If we can't
provide a unified sync solution thats well integrated into the desktop
then the GNOME Online Desktop stuff will. And it won't learn from
conduit or opensync. It will reimplement sync on its own. And its
already begun.

John