Re: Ubuntu UDS-Boston, Syncing solutions

Martin,

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
    --> Focus more on online services
    --> Focus on a attractive file sync use case (not rsync level, but
workable for hundreds of files at a time)
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

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

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
   --> I have thought long and hard about making the command line
tools syncml-obex-client and syncml-obex-server into dbus daemons .
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). 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.

Anyway, thats a bit of food for discussion off the top of my head. Is
there some way I can participate in the Ubuntu discussion remotely?

John Stowers


On 10/31/07, Martin Owens <doctormo@...> wrote:

    Hi everyone,

    I've pushed the syncing engine and support issue into the UDS as I'm
    here all week; I want to talk seriously about how we can start to
    integrate conduit and opensync in a coherent set of functionality for
    the ubuntu desktop.

    I'm sure many of you will be familiar with my emails in the past, I am
    unhappy about the current dispersed and non integrated fashion with
    which this functionality is being developed. but I want to talk about
    it in the context of ubuntu.

    So if you have any issues you want me to bring up; or your attending
    and would like to take part. please do reply and register on the
    blueprint as required.

    Best Regards, Martin Owens
    _______________________________________________
    Conduit-list mailing list
    Conduit-list@...
    http://mail.gnome.org/mailman/listinfo/conduit-list




On 10/31/07, Martin Owens <doctormo@...> wrote:
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel