Re: [Opensync-devel] Getting things back on track

[Bjoern R. <bjo...@go...>]

Hi,

as this discussion pops up every few month I didn't wanted to write an
answer again and again. We know that the current development situation
sucks and that our BUS factor is critical. I guess 70-80 percent of the
knowledge about opensync is in Daniels mind. That's not good and I am
willing to change that. But last year we tried to change this situation
with weekly IRC meetings and it ended up that only Daniel and me were
participating. That's really frustrating.
As I wrote before all people (especially from akonadi) blame us for not
being ready. But the big difference between e.g. akonadi and opensync is
that akonadi has several full time developers and it's part of KDE.
Therefore there is a high interest of companies in akonadi. This isn't
the same for opensync. We are only a very few people (currently only
two) who are working in their rare free time as a hobby on a very
complex framework for synchronisation. There isn't any company which is
currently paying a developer to work on it full time. That's it. And
Daniel and me can't promise any release dates because there is a private
life and a job besides opensync.

> On Mon, 19 Oct 2009, Henrik /KaarPoSoft wrote:
>   
>> OpenSync 0.40 seems just around the corner, but so it did 6 months ago,
>> and 12 months ago.
>>     
>
> Well, it gets further and further away mostly for two reasons: (a) various 
> people having less time to work on it (the problem we are trying to solve); 
> and (b) adding extra features. The latter hasn't been so much of a problem 
> recently but during 0.40 lifecycle a *lot* of new features were added. IMHO we 
> tried to produce something perfect for the 0.40 version, and so bit off more 
> than we were able to chew. I get the impression that most of the hard 
> implementation work is done though, and I think we've now reached a stage 
> where we should not be considering (or even need to consider) adding anything 
> major to the API.
>   
Thanks for your mail Paul. You are completely right. The current version
(0.39) is indented as something like a beta version of opensync. Most
parts of the API won't change until 0.40 and now it's time for plugin
and app developers to try it out. Of course there exists a lot of bugs
in this version because it has a lot of new features which aren't tested
in real scenarios. It's a synchronisation framework and synchronisation
as all people know is very difficult to handle. Don't blame us for bugs.
Two people can't have all plugin/app use cases in mind and produce a bug
free sync framework. But we have a nice feature rich framework that
could cover most of all pim related use cases and there won't we any
knew feature for 0.40.
>  
>   
>> My own "personal" goal is: From my Linux or Windows desktop, to sync
>> Mozilla Thunderbird and Sunbird to any SyncML capable phone.
>> Or, I guess more generally, to allow an end user to:
>> Synchronize "any contact/calendar source" with any other such source(s).
>> Where a source could be a local device (mobile phone, PDA, etc), a local
>> application (Thunderbird, Outlook, KDE Pim, Evolution, etc), or a remote
>> application (GMail, etc).
>>     
>
> I like OpenSync's overall goal - to provide the framework that allows 
> synchronisation of PIM data from anything to anything. Nobody else in the open 
> source arena has ever done this before*. Heck, few high-profile products in the 
> commercial world can do this, as far as I know. Nokia bought IntelliSync some 
> years ago but I've heard little about it since then, and frankly I doubt it is 
> capable of all the things OpenSync is designed to be. It's ambitious, sure, 
> but given enough resources I don't believe it's impossible.
>
> (* - well, Conduit is equally ambitious, and at the outset there was hope that 
> they would be able to collaborate with us; I know John Carr really tried hard 
> on this one, but ultimately they weren't sure how to integrate OpenSync into 
> their system and we weren't ready ourselves. Last I heard (over a year ago) 
> they were still discussing how to handle some of the classic synchronisation 
> problems with PIM data (like conflict resolution) that OpenSync at least in 
> design had already solved. Anyway let's not dwell on past events - let's focus 
> on the present.)
>   
That's it. I guess everytime people are going to start a new sync
project for PIM data the will run into the same problems as opensync.
There have to be a lot of feature sets for different scenarios to not
lose any kind of information. OpenSync does support these features. They
aren't bug free as I said before but we spend a lot of time to get a
future proof framework. Therefore we tried to get rid of the hard coded
xmlformat dependency also. Now it is only a "soft" dependency which we
can change in the future easily. That doesn't mean that we are dropping
xmlformat in a next version. But we could if it will be necessary.
That's future proof.

Can't say anything about the feature set of SyncEvolution and I really
don't want so write any comparison. But if it is easier to handle for
any use case why not try it out. It's open source. It's your choice. You
are free to make your own decisions. But as a developer of opensync I
can say that our framework supports (nearly) all use cases already. I
don't think that SyncEvolution can handle different capabilities. But
you can say "why should I need capabilities". And in some scenarios you
are right. You don't need them at all. But at some point in the future
with a lot of different devices and applications your will know what a
great feature these capabilities are.
>   
>> OpenSync - if we ever deliver - would implement most of "my objectives",
>> but:
>> - will we ever deliver?
>>     
>
> That is a good question. I think we can, but it can't be done just by two or 
> three people. We need to widen the participation.
>   
Yes we will finish it. But I can't promise any release date.
>   
>> - OpenSync has invented it's own protocol - though SyncML is also
>> supported via plugin.
>>     
>
> I'm not sure what you mean. OpenSync's original design did revolve around the 
> internal XML format though. This is now semi-deprecated, although I have to 
> admit I am not clear on the details of how that has/will happen - that is 
> something to discuss/document definitely. FWIW xmlformat is largely an XML 
> representation of the vFormats anyway, so it's not particularly unusual.
>   
As a mention before xmlformat isn't deprecated. We are relying on that
format but NOW it is possible to change that dependency easily.
Currently nobody is going to remove or replace xmlformat.
>   
>> - OpenSync will require custom-made plugins for each data source to be
>> supported.
>>     
>
> That is true. What is also true is the barrier to creating a new plugin is 
> quite high - there is a lot to implement for a plugin writer and it has to be 
> done correctly or things will go wrong during sync. Honestly though with the 
> variation of different targets to sync with I'm not sure there is a more 
> effective solution.
>   
We wrote some example plugins which should help to understand the plugin
api. There is a lot a stuff which a plugin could use but it don't has
to. It always depends on the use case.
> It was supposed to be possible to write plugins in Python at one stage, I 
> personally do not know the status of this - does it still work?
>   
The python wrapper doesn't work currently because there isn't any
developer who is able to fix it. I don't know python so I can't do that.
But it should be difficult.
>   
>> Let's create a new project (called newSyncML? OpenSyncML? ???)
>>     
>
> The solution you propose is (AFAICT) the approach Patrick & co. have been 
> taking with SyncEvolution. It looks to be working well for them and I 
> certainly wish them all the best; for modern devices SyncML is becoming 
> universal.
>
> However, the targets I am considering (and AFAIK the one which you mostly work 
> on, Mozilla) can't rely solely on SyncML however. That is where a lot of the 
> problems lie in my opinion. Reducing this down to a simple translation layer 
> between SyncML and any other synchronisation system I believe may be 
> oversimplifying - I think there's a lot more work there than you may be 
> thinking of.
>
>   
>> Daniel and others, I am sorry, but this is really a call for "Don't
>> throw good money after bad".
>>     
>
> Personally I don't think we've reached that stage - there is also the saying 
> "don't throw the baby out with the bath water". I truly believe the concepts 
> in the design behind OpenSync are solid. Some of the implementation and 
> details leave something to be desired; but starting completely from scratch 
> will simply mean rewriting the same things again, perhaps just in a different 
> order. I don't see much benefit in that, and it will certainly take a lot more 
> time.
>
> Cheers,
> Paul
>   
-- 
/Bjoern Ricks