Hardy: Time for sync project focus and here is how

[Martin Owens]

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

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

> 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?)

No attacks from me, just questions and positions; outlines and thoughts.

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

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

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

That's the idea, layers rather than conflict, if you can move all your
sync layer to open sync, keep your dbus and clever intergrations layer
as conduit then we'll all be happy.

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

Help them fix it if you can, no one's perfect although sometimes
people are very prideful of their api's.

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

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

Good enough for me.

> I don't know how better to word this. So here goes. We wanted to make sync rock.

Don't we all.

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

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

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

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

Best Regards, Martin Owens