Re: [Opensync-devel] Ubuntu UDS-Boston, Syncing solutions
- From: Daniel Gollub <dgollub suse de>
- To: opensync-devel lists sourceforge net
- Cc: Conduit <conduit-list gnome org>, John Stowers <john stowers lists gmail com>
- Subject: Re: [Opensync-devel] Ubuntu UDS-Boston, Syncing solutions
- Date: Wed, 31 Oct 2007 12:16:55 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]