|
From: Chris F. <cd...@fo...> - 2011-01-03 21:05:49
|
On Mon, Jan 03, 2011 at 02:32:52PM +0100, Patrick Ohly wrote: > Of course I am thinking of SyncEvolution here. It already works very > well for SyncML. I also have support for additional protocols, which I > will be able to publish soon. I think it would be worthwhile successor > of OpenSync, but obviously I'll need help to cover all the use cases > that you were shooting for with OpenSync. My personal opinion is that the steps of your proposal are just slightly backwards. I think that before we declare anything dead, that the replacement should first be just as much alive. Alive in the sense of features. Otherwise people will just continue hacking on the design they like best. So I'm also interested in the answers to Graham Cobb's questions. If there is something that OpenSync can do today that SyncEvolution can't, then that should be fixed before OpenSync dies. The project that is most useful and supports all useful features is the one that deserves to keep going. But in the meantime, I don't believe there is any harm in having both. It's the Linux way. :-) In other words, if you want the support of the OpenSync developers (such as it is), implement OpenSync's features in SyncEvolution (and maybe even change the name, since it sounds overly linked to Evolution syncing) and you'll win automatically. You won't need proposals. You'll have the features, and therefore the users *and* the developers. - Chris |