Hardy: Time for sync project focus and here is how

[John Carr]

> Am Samstag, den 01.09.2007, 02:24 -0400 schrieb Martin Owens:
>> Hi all,
>>
>> I'm posting this here because that is what some guy in #ubuntu-devel
>> told me to do to get a better discussion going.
>>
>> Basically in the launchpad blueprints list there are a few tickets to
>> look at for existing complete ideas:
>>
>> https://blueprints.launchpad.net/ubuntu/+spec/ltsp-palm-devices
>> https://blueprints.launchpad.net/ubuntu/+spec/pim-device-sync
>> https://blueprints.launchpad.net/ubuntu/+spec/pocket-pc-support
>> https://blueprints.launchpad.net/ubuntu/+spec/pda-support-out-of-the-box
>> https://blueprints.launchpad.net/ubuntu/+spec/syncintegration
>>
>> The new idea is to use _all_ the tools we have at our disposal to
>> engineer a system which will be robust, functional and should be made
>> to show how god awful syncing on other platforms is currently done.
>>
>> Tools: OpenSync, Python/Gtk, HAL/DBus, BluetoothTools
>
> Have you already looked at Conduit yet? Seems to be a good framework,
> that is (gets) highly integrated into the GNOME desktop and would need
> some love to get SyncML working.
>
> Cheers,
>
> Sebastian
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>

Hi Sebastian

I've been talking with Martin about Conduit on ubuntu-devel-discuss. The
thread is here:

http://thread.gmane.org/gmane.linux.ubuntu.devel.discuss/1605/focus=1614

I'm CCing devel-discuss because i no longer have any idea where this
belongs! Sorry if I spam anyone.

I think we've established a good ground for moving forward with a combined
effort to make sync "just work", and not just for the PIM <-> Device case,
that is cross desktop.

Obviously as we are a GNOME group we'll need help with KDE and Xfce. A big
area of work in our framework lately has been to define much better
interfaces between the components so we should be able to separate out the
GNOME specific parts quite easily (basically the GUI and the GNOME
specific dataproviders we ship).

That will leave a reasonably light weight dbus interface that can be used
to control OpenSync (or optionally or our sync engine, depending on the
state of their current trunk series in April). It will also take care of
HAL, NetworkManager and other integration stuff.

Conduit will also bring 17 of its own dataproviders to the mix, hopefully
including our PC to PC sync utilising avahi work, which is currently in
"alpha" in our trunk.

Imagine these two use cases that Conduit+opensync is already very close to
delivering - opensync alone leaves you with a *lot* to do.

(1) You connect your new phone for this first time using USB. The Conduit
service detects that it has a dataprovider for this device and raises a
dataprovider-available signal. This signal triggers a "New device, do you
want to set up sync?" notification bubble. (Serial or some other unique id
is logged so that the user doesnt get spammed on every connect?) On
subsequent connections, the partnership is detected, and a sync will just
happen.

(2) You connect to your network. Conduit senses the connection and makes
the networked dataproviders available. (E.g. Google Calendar). A
partnership between KDEPIM and Google Calendar exists, a sync is
triggered. I can't speak for KDEPIM, but in Evolution we can monitor for
change events and trigger syncing automatically.

I am a voice of Conduit, but not the BDFL so i'm going to speak/defer to
the team before I commit to any specific action points, but we are quite
an agreeable bunch. And i'm quite eager to make all this a reality in the
HH time frame.

John