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?
>
> Apologies, I obviously came over wrong; maybe a cultural thing. I like
> to engage in passionate debate, but I have no interest in flame wars
> or fighting.

Eh, some say that for a yorkshire lad i'm a tad sensitive, i'd tend to
agree. I just wasn't prepared for such a full frontal assault, especially
with my pride (in Conduit) taking a big hit.


>> 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 about now? is the API cleaner, are you able to help them clean it
> up; can you bring your experiences to their problems etc?

I think I made it clear to them when we started talking in earnest about
our options for moving forward. Regardless, the python bindings have
improved a lot and as I hit problems I know who I need to speak to now.


>> 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.
>
> Hopefully you'll allow more than one route (and you I believe via
> dbus) so weather I create an api for opensync directly or for conduit;
> I want to make sure that _all_ the bits are are going to be there and
> that I don't have to start porting barry or wme plugins to conduit.

For the purpose of discussion, it might be useful to break Conduit up into
3 parts. We really have a GUI and a sync engine. We also have a manager
layer that takes care of HAL and other "automatic" stuff. Everything our
GUI consumes comes from the manager layer. If everything was going to our
plan then your tools would build around our that layer. You wouldn't need
to worry about which sync engine was used - conduit would make sure that
everything just worked.

I hope Conduit will be able to take advantage of PackageKit to
automatically install needed support packages (I don't think its wise to
support every device officially - some of the configurations are *very*
flakey. Not opensyncs fault, just bad vendor implementations and such.

Basically, I would hope that instead of abstracting our abstractions you
would help us improve them. We are quite accepting of things that improve
our interfaces and not afraid to fix our badly broken designs.

Unless i'm misunderstanding your intentions again!


>> 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!
>
> Only the backend, I'm going to make a modified version of my diagram
> with conduit involved and I want you to let me know if it fits in with
> what you want to do.

Cool. I'll try and do a diagram of how things would look at the moment
with Conduit on a naked Gutsy.


>> 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.
>
> So long as your intergration is more than just using opensync as
> another end point and it's a more serious and dependant stack.

Using opensync as an endpoint (like that term btw) was phase 1, which is
almost done. Thats going to pay off for you guys because we'll pretty much
take care of mapping HAL to sync endpoints. Also starting phase 2, I'm
starting to do with using the sync engine itself. Which is a weird
experience, because the API is seemingly entirely different. Assuming we
haven't found massive problems at this stage then we'll go into phase 3
and starting make stuff available from "pure" opensync.

(Its worth noting the planned timescale on this is quite short)


>> Things like this shouldnt involve a thousand packages and archaic
>> command line tools.
>
> right, but those tools should be there anyway; some people just like
> it that way, no beating up CLI's please.

As a seasoned irssi fan, i'm not anti-CLI. I just wanted to be clear that
making the user need a CLI at any point, I'd consider that a failing on
our part.


>> 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.
>
> Your going to effectively keep two streams of development going? at
> the same time as pushing your current base your also going to be
> making sure those features are made available to opensync so when you
> do move you don't loose features or time?

Exactly. You have to understand that.. it turns out that the actual
syncing is a teeny tiny part of our stack. The actual sync logic needs
next to no maintenance and most of our work at the moment is on making the
platform more useful to developers and increasing the number of plugins.


>> The UI looks kind of device centric. Conduit doesn't hide options from
>> you
>> like that, you simply see what you can sync.
>
> The UI is simplistic, nothing says I can't make a link in that menu to
> load conduit gui and have each one of those menu items as a simple
> interface (via dbus) to what conduit is providing. then I wouldn't
> need to do very much at all; but conduit needs to be able to support
> syncing without loading the large gui for that to work.

Thats cool. Conduit can take a command line option to start without the
GUI. It can also be dbus activated without the GUI. Finally, it can be
installed as part of the desktop session and will run without a GUI until
you start the GUI through the Applications menu.


>> 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.
>
> I'll continue to deliberate the best course of action, obviously
> you've said your moving towards opensync integration which is great;
> I'd rather see it sooner rather than later though since it would allow
> me to move forwards.
>
> Sorry again for the culture clash in my first email.


Conduit (head/trunk) will be available with opensync before the opensync
meet. Simply as i'd like to be able to show off a little in Germany! But
the internal sync won't be culled for a while. Even if we decide its not
the default, it will still be a backup option. (As i've said, its compact
and easy to maintain).

John