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

[Daniel Gollub <dgollub suse de>]

On Wednesday 31 October 2007, John Stowers wrote:
> I'm sure John Carr will reply to this mail also. I can only speak for
> my own intentions and as such I have generally been doing the
> following with my development time (in relation to Conduit + Opensync)
>
> 1) Trying to work on areas that opensync does not explicitly target
> (for example, not a complete list obviously)
>     --> GNOME online desktop type foo
>     --> Provide a great GUI
Agree, OpenSync stays desktop and platform independent....

>     --> Focus more on online services
We might conflict here - since we would provide our own set of OpenSync 
plugins. Currently we limited our self to PIM data .. since OpenSync is 
awesome for syncing content-related data in little size - like PIM data ;)

Example: google-calendar plugin (Could need more love - we need support for 
the latest GCal API features, like batch processing and the calendar 
ressource API)

>     --> Focus on a attractive file sync use case (not rsync level, but
> workable for hundreds of files at a time)

Hmm, this might conflict with csync ... I'm in contact with the author of 
csync. He evaluated OpenSync before i started with csync implementation. 
Actually it is his diploma thesis, so the quality should be quite high. It's 
like OpenSync+rsync - it doesn't touch the content like OpenSync could to 
converter between different formats, it supports bidirectional 
synchronization, rsync only supports uni-directional which isn't acceptable 
for a default-desktop-user.

> 2) I am also trying to actively make our Conduit core more
> integratable with opensync plugins
>     --> Support both hashes and mtimes
>     --> Be smart with object comparison and rebuilding relationships
>     --> Remove all gnome/gtk dependencies in core
>     --> Reduce memory consumption
>     --> Etc

This sound like completely hijacking the OpenSync synchronization logic :)
Or maybe i missed something...

I know about the idea of J2ck to have a solution to provide different 
synchronization logic - not quite sure about that yet if this should really 
done in this way. Since we could waste a lot of time with double effort ... 
and for sure currently conduit can compare with the synchronization logic of 
OpenSync - actually I'm not aware of any powerful synchronization logic like 
the one OpenSync has - even the propertaries ones.

>
> I think John Carr has lists similar to above. Although Conduit has not
> made its position wrt opensync publically obvious, I think we all
> agree that blatantly racing to implement the same features helps few.
Agree...

> I was perhaps guilty of this when I added evolution support using our
> own python evolution bindings, but in my defense I think its negligent
> that evolution/gnome didnt provide bindings for eds already.
We currently suffering also with the evolution-data-server and it's interface 
as well .. but not because of python bindings. We have to run the evo2-sync 
plugin in a separated process.

>
> Furthur to that the following is a list of areas that I have avoided
> development work on so far. This is both because of time issues, and
> because I wanted to agree on how to procede together first.

>    --> How can we use HAL to encapsulate the sync capabilities of a
> device. Such as have fields in FDI files that describe a mobilie
> device as having "Notes", "Contact", etc data to sync
That would be indeed very intersting. But i hope you agree that we don't want 
to create tons of separated FDI files to list all the device capabilities. 
Only because of the  reason it's easy...

We should kindly ask the HAL developers to add support for certain protocols 
and probe them if a device got attached. Examples:

- HAL request and provide x-obex/capabilities information from OBEX interfaces 
(not only list obex interfaces...). With those capabilities we could not only 
provide  sync capabilities for SyncML and IrMC ... also provide information 
about OBEX FTP.

- Palm HotSync interface - in HAL are currently ugly FDI files to point to the 
correct usb serial interface for HotSync. Since pilot-link 0.12.x it support 
transport via libusb and there is no need to "guess" the usb serial 
interface. The libusb transport code of pilot-link handles this in a more 
sane way... lots of pilot-link frontends like gnome-pilot and kpilot afaik 
suffer on this. gnome-pilot for example listen for HAL and if the FDI 
property of this ugly FDI file got set it tries to start a sync. Even if the 
palm device doesn't is in "hotsync mode". Newer palm models even appear on 
USB even if their not syncing. But the disappear and appear again with in one 
second if the cradle got pushed.

- Not quite sure about all the Windows Mobile devices.. i guess J2ck is more 
familiar with that...

Regarding Bluetooth on Linux the BlueZ developers did a really nice job with 
the BlueZ D-Bus API. I missed the last BlueZ Developer meeting but there are 
still plans to get BlueZ integrated in HAL. Anyway so far I'm quite satisfied 
with the current BlueZ API. You can get everything what you need with the 
from the SDP records. It's even possible to do some periodic device 
discovery.

>    --> I have thought long and hard about making the command line
> tools syncml-obex-client and syncml-obex-server into dbus daemons .

I fully disagree ;)
There is something called HAL...
It's just about x-obex/capabilties - you should have a look at the OBEX spec.

> The FDIs in this case could also encode the quirks and specific syncml
> config attributes for the phone, if connected over USB (see the
> opensuse wiki for a list of these). 

I heard of quirks and i really don't like quirks. Especially i don't like 
quirks if it's possible to avoid quirks if the device protocoll fits all your 
needs ...

> At this point I would (1) 
> communicate with the daemon from conduit over DBus. I would also (2)
> rewrite the opensync syncml plugin(s) to communicate with these
> daemons over dbus. Obviously I have not yet considered how much work
> (2) is, and even if its possible. While this still has some code
> duplication, its at least an effective middle ground (through
> libsyncml). I would appreciate your thoughts on this.
Sorry, this is really not needed. You should have a look on the OBEX Spec.
The commandline tool obexftp has a simple reference implementation how to 
request the x-obex/capabilties. "obexftp -X"

If  the HAL developers don't fully disagree with my idea of implementation 
there is no need to have yet another system daemon.

But i see your point in have same process/daemon running which takes care  all 
the time about triggering a sync or reporting there is a new and unknown 
device which could be synced.

I already had an idea about a (D-Bus) session daemon (which is desktop 
independent), which could handle mobile devices related stuff. Like 
triggering a sync if your local PIM environment added a new bunch of new 
contact entries... so periodic sync like every 5 Minutes is not needed. I 
would suggested to only do syncs if the device appear and is after 5 Minutes 
still available. I called this "MobileStation" - anyway thats quite offtopic 
now ;)

best regards,
Daniel