Hardy: Time for sync project focus and here is how

[John Carr]

Oh, ouch. I can't think of words for how.. "well".. I took your reply.
Well I can, but it wouldn't give a very professional image of my project!
Do you represent Ubuntu? You do seem very angry about something, I hope it
wasn't something I did to offend you?

>> We provide a GUI and dbus mechanism for syncing on the free desktop. We
>> support our own sync-engine core but are working to support opensync as
>> well. We can sync your applications to devices, to other boxes on your
>> network and to various "Web apps". We hope to become a stock GNOME
>> application in the medium term (and are moving over to GNOME hosting as
>> we
>> speak).
>
> Hit nail on head: you have your own sync engine... any reason why or
> you just thought it'd be a laugh to cause major integration headaches?
> Do you have a plan at some time in the future to scrap or merge your
> sync engine into opensync and dedicate your back end syncing services
> to that?

I cut my reasons out of my original e-mail. Conduit has been around for a
while, and when we tried to use opensync.. we had issues. Issues we
submitted patches for. See the opensync mailing list archive. Ultimately
we couldn't, then at least, achieve the experience we wanted to using
opensync.

What I didn't cut out of my e-mail is that we are trying to use opensync
now. Not just trying, but I am actually going to meet up with them in
Germany at the opensync meet. Ya know, i'm going to fly there using my own
money and work on a unified sync. Not tea and biscuits with grandma, but
tea and biscuits with the guys that you are purporting to stand up for.
Hopefully some of the stuff we do in Conduit will move upstream/downstream
as a result of this event. Cos I believe in co-operating and stuff.

So please don't use that as a base for your attacks on me and the project
i've spent the last year working on, when i'd guess that I have way better
links with their devs than you. (Unless i'll see you in Germany?)

>> Martin, you ask what we can provide. Hopefully I can persuade you that
>> the
>> answer to the spec is to deliver Conduit to Ubuntu users rather than
>> implement a 4th GNOME front-end to opensync.
>
> We'd like very much to write a front end that isn't built by palm
> desktop copy cats and non-thinking windows tracers who seem to make
> gui's based on what thier used to rather than what would really be
> good. So no it's not a 4th opensync front-end, think of it more like
> the 1st gnome, kde and xfce gui plan.

I think I mentioned that we plan to support other platforms. Hildon should
be quite easy, and the others aren't exactly difficult. GUI wise, its
certainly quite different to any sync software i've seen.

> At this point I'd think your post goes a little too pitchy, you don't
> have to sell anything to me; I just want good technology that isn't
> shackled to daft legacy problems down the road.

As I said, I was trying to give a rough outline of what we are working on,
and that i'd happily answer specific questions. If I had gone in to
details my audience would have fallen asleep on me! If we have daft legacy
problems let me know, thats the last thing I want!

>> I also own a Windows Mobile device so expect WM5/WM6 to "just work" in
>> the
>> near future. Generally if it has opensync support, or dbus bindings of
>> some kind, then we can support it fairly easily.
>
> Here's your steps you should be working on:
>  * OpenSync on DBus, work with opensync team
>  * Create opensync plugins for all functions not currently available
>  * Decommission conduit sync engine

My discussions with opensync clearly haven't been open enough! Yes, thats
kind of the goal. Not entirely sure what you have in mind for OpenSync
dbus but its probably something i'm already in contact with them about.
One suggestion from opensync was that part of Conduit might actually
become a cross-desktop dbus daemon for discovering which
plugins/dataproviders are available. It could take of the HAL and other
discovery mechanisms. GUI building would then be as trivial as possible.

I also suggested a dbus way of creating groups and syncing, though i don't
think a desktop syncing service with dbus control is part of their
roadmap, where as for Conduit it is. And thats what you get.

I'm not sure what you mean by creating plugins for functions? I presume
you mean plugins for applications, devices and web services not currently
available? Personally, I hope I can persuade opensync to simplify their
API. I personally find our API easier to get going with. (I had tried to
use opensync last year for a personal project, and failed. Then I was
pointed to conduit. In comparison, it was a dream to hack on).

Regardless, phase 3 of my integration work revolves around making sure
that all 17 of our plugins are available to opensync. Otherwise, I won't
be able to use the opensync engine to sync them!  When thats done, Conduit
and OpenSync will have more than 24 different supported sources / targets.
Yes, that was a less than gentle hint that we are bring quite a bit to the
party.

Decommissioning the conduit sync engine is the end goal, but we depend on
an alpha version of opensync at the moment. We will go to opensync by
default when our tests show it is ready.

> Your gui is nice, and we need great services not tied to the gui or
> the way it's designed; so if you work with open sync people we would
> all get the benefit regardless of interface.

Our service isn't tied to the GUI. I guess I forgot to mention running our
framework on a server. Not quite ready yet, but also not too far away. I
plan to run Conduit on my Linksys NSLU2. My photos, contacts and calendar
will be automatically kept up to date between machines that can see the
server. I get multiple backups relatively cheaply.

>> Personally I think that with some help on the upstream bits (bluetooth
>> HAL
>> polish) and Conduit finishing off the opensync bridge (to enable more
>> PDA/Phone support), Conduit can deliver this spec and a whole lot of
>> other
>> tasty synce features for Ubuntu. With a KDE/Python volunteer we should
>> be
>> able to get there for for Kubuntu too.
>
> You have to ask yourselves; are you a gui project that was forced to
> make it's own services or a services project that had the compulsion
> to make gui? because if you try and do both you'll just end up doing a
> bad, non-modular and fairly non-intergenerational blob. Besides you
> didn't even comment on any of the presented ideas in the wiki.

I don't know how better to word this. So here goes. We wanted to make sync
rock. Things like this shouldnt involve a thousand packages and archaic
command line tools. We tried opensync, it caused no end of problems. We
just couldn't get it to work how we had imagined it should work. Working
upstream, we failed. In a relatively short space of time our own sync
engine was rolled. We found problems and solved them. Because we wanted to
be "good" we tried to expose our services using dbus. Now no one will ever
need to do this again! (But we were wrong there, oh so very wrong. Now
even tomboy has its own sync engine!).

Now we are trying to integrate OpenSync because it seems like the decent,
proper thing to do. It's not because of a feature difference, the only
thing that the opensync engine buys us is merger/demerger.

The question we have to ask is, do we want to destabilize our code base
for months and wait for merger/demerger to be ready? We've tried to be
realistic. By keeping our APIs sane we can support lots of combinations on
our own. We can get them working and kicking some ass. We can then
transparently switch to opensync when its ready.

We've had over a year working this way to become an non-intergenerational
blob. How are we doing?

Re the wiki, steps 1 and 2 are vaguely similar to the things I hope to
discuss with opensync in germany. I also want to map devices to plugins
using HAL, otherwise each UI has to implement its own discovery code. Step
3 would need doing anyway. Step 4 is taken care of for you by Conduit.
Both in the GUI, and in the Dbus API with DataproviderAvailable and
DataproviderUnavailable notifications among other things.

I don't understand the diagram that well. Though it looks like Conduit
could handle most if not all of it right now, just needs some polish to
get those opensync plugins playing nice with hotplug.

The UI looks kind of device centric. Conduit doesn't hide options from you
like that, you simply see what you can sync.

Use case 3 can be done with Conduit trunk. Use case 1 and 2 should be
taken care of before I go to Germany.

I really don't know what else to say. Theres nothing specific in that spec
that I can comment on. I'll have a think on the train, but i'd really just
want to apt-get install conduit so far. Nothing there that is OMG, no way
can Conduit do that !?!!! Quite the opposite. OMG, why isn't Conduit doing
that!?!?!

> I'm going to make sure the wiki is updated with the conduit info, but
> I'd rather see less of a need to choose between opensync and conduit.

There wouldn't be a need to choose, we have a pretty large test suite and
i've already begun wiring OpenSync in (so they'll benefit from our test
cases too). Ultimately, we'll decide which engine is the best choice for
our users.

John