Hardy: Time for sync project focus and here is how

[Martin Owens]

> I'd like to discuss the aims of Conduit and how we can reduce the
> duplication of effort on the sync front.

That is what I would like to talk about. Conduit is nice, all very
nice; like a cup of tea and some custard creams round your
grandmothers nice. but....


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

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

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.

> 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

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.

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

Best Regards, Martin Owens