opensync-devel Mailing List for OpenSync (Page 39)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Dear fellow developers,

Please review the patch attached to
http://opensync.org/ticket/1172

Should I commit?

Thanks in advance
/Henrik

Dear fellow developers,

Please review the patch attached to
http://opensync.org/ticket/1173

Should I commit?
And should I do the same to other similar properties?

Thanks in advance
/Henrik

Am Montag, den 19.10.2009, 18:29 +0200 schrieb Daniel Gollub:
> [...]
> I want to suggest now that we _all_ should try something new:
> 
> We look for volunteers who are interested in becoming OpenSync core 
> contributors and assign special components of the core to them. There is no 
> deep knowledge in OpenSync core development required today ... just the 
> willing to help the OpenSync development and maybe some very basic C 
> programming is required (i leanred C also while programming on OpenSync ... so 
> don't hesistate to start here as well).
> 
> My role will be just kind of a mentor, and i just try to be available for 
> question as much as possible and will do only developing and debugging if 
> there is no pending questions from the other core developers.
> 
> Are there any volunteers for following components?
> [...]

Yes there are. My name is Dirk and i am new to opensync. I am reading
this mailing list in a while and I am interested for this project.
I am studing computer science. I had considered some time ago to expand
my programming skills to participate in an open source project times.
Unfortunately I have only basic skills at this time.

But I hope I can help you?

Best regards

Dirk

Some elements in an xml format can have attributes, such as:
<Address Location="Home">
Is there any way to define which such capabilities a plugin supports?

One plugin may support only one address without specifying location,
another plugin may support only Home,
and a third may support Home and Work,
etc.

If I want to provide a static xml file with capabilities for my plugin 
instead of using osync_capability_new in code, what do I call the file 
and where do I put it?
Also: is the correct root element in the XML <capabilities> as in 
xmlformat test cases or <Cap> as in the group files ?

On Tuesday 20 October 2009 06:35:51 pm Henrik /KaarPoSoft wrote:
> Until now, when I have found bugs, I have filed tickets - sometimes with 
> patches.
> As a result, others have either rejected the patches, committed them, or 
> committed them in a modified form.
> Would it be beneficial if I just check in my patches directly?
[...]

I would say this depends how complex your modification is. If your sure this 
is a trivial modification go ahead and commit it (and make sure it passes the 
entire testsuite and doesn't cause any regression).

If it's a more complex chance please always send the patch to opensync-devel 
and ask for review. If there is no response within 2 days, feel free to commit 
it directly ...

Does this sounds sane to you?

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Daniel Gollub wrote:
> Hi,
>
> we have a pretty low BUS factor [1] for OpenSync core development. Which is, i 
> guess, the primary reason why the OpenSync development is so slow ...
>
> Everytime when Björn or I disappear for some weeks the development is kind of 
> frozen.
>
> We look for volunteers who are interested in becoming OpenSync core 
> contributors and assign special components of the core to them. There is no 
> deep knowledge in OpenSync core development required today ... just the 
> willing to help the OpenSync development and maybe some very basic C 
> programming is required (i leanred C also while programming on OpenSync ... so 
> don't hesistate to start here as well).
>   
The mozilla-sync plugin is more than enough for me already, so I cannot 
volunteer for maintanership of any parts of the OpenSync core.

However, I do have a question:

Until now, when I have found bugs, I have filed tickets - sometimes with 
patches.
As a result, others have either rejected the patches, committed them, or 
committed them in a modified form.
Would it be beneficial if I just check in my patches directly?

(Bear in mind, that I still understand so little of OpenSync, that in 
something like one in three I am wrong and break things.
So it would be a two steps forward but one step back approach)

/Henrik

Just for the record:

I am *still* devoted to OpenSync.
But since I have still not been able to produce a working blueZync for 
years, I certainly am very frustrated.
That is why I am at the same time looking for alternatives to OpenSync 
(maybe a bit unfair to discuss this on OpenSync mailing list and IRC, 
sorry for that).
But I have not yet found a better alternative that I believe would be a 
faster/easier/smarter way to a working blueZync...

/Henrik

On Monday 19 October 2009 21:37:13 Chris Frey wrote:
> 	- everybody is using the latest code
> 	- any bug that needs to be fixed, or feature that needs to be
> 		implemented, will be felt immediately
> 	- anyone who feels that need, will have the ability to scratch
> 		that itch immediately, and see their work released
> 		within a month, thereby solving both OpenSync's problem
> 		and their own in real time

> People need to be invested in the current code, not 0.22.  Right now,
> 0.22 doesn't solve their needs, 

That's what i suggested a long time ago. We need to officially
announce 0.22 dead, kill it. Fedora upgraded their versions to 0.3x and
then reverted back to 0.22 even i tried to stop that idea there too. :)

If you want to keep everyones eyeballs out of focus (current code), best
way to do is to distract them to look something else. _Opensync is a name
that stands for the concept of pda syncing_. Everyone knows it already.

People stare at the 0.22 and see that's it is not good for anything else 
than filling a package in distro.

That damages both our needs (more eyeballs) and the name. There is no need 
to keep an active placeholder in distros, since everyone knows the name already.

So, i suggest (with quite minimal effort):

- drop 0.22
- leave space empty or...

  Perhaps we should just lift the ban to upgrade distro releases for 0.39?
  That is - announce that it's very close to finished API and everyone should 
  package it now, since once the possible fixes to API happen in next releases,
  those will not be big changes in apps and wont cause lot to work to update.
  Then it would not break the promise of 0.40 with stable api and make people
  stare the current code.

There are not many (or none) using the 0.3x api except our own tools, so people
using those would be able to easily test it via distro packages and we would
be able to do the remaining work until anyone really puts lot of effort to 0.39
api in app - which anyway wont be that much different from 0.40 proper.

btw, Chris you've very valid points in your comments, keep them coming.

Tuju

-- 
Better to have one, and not need it, than to need one and not have it.

> On Tue, 2009-10-20 at 09:55 +0200, Bjoern Ricks wrote:
>   
>> But as a developer of opensync I
>> can say that our framework supports (nearly) all use cases already.
>>     
>
> Do you support the use cases theoretically or in practice? My
> understanding is that "vCard 2.1 (phone) <=> vCard 3.0 (Evolution)" does
> not work. Nor does vCalendar <=> iCalendar. In my opinion the "future
> proofness" of OpenSync is mostly theoretical at this point. I'd be happy
> to be proven wrong, of course.
>   
That's a format dependent problem. In the past cstender kept an eye on
vformat. Of course there are issues with format conversion, because that
vcard, vcalender, ical, ... stuff is very complex too and every
application and device is handling it differently. But in opensyncs view
it is only a format and formats are separate plugins which provide
conversion routines. That should be relative easy for EVERY programmer
to fix if he knows some details of these formats.
>   
>>  I
>> don't think that SyncEvolution can handle different capabilities. 
>>     
>
> This is incorrect. Please have a look at
> http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard
>
> It explains how the Synthesis engine uses capabilities to determine
> which properties are supported by a peer and how it generates that
> information automatically from the data format description. In contrast
> to other SyncML libraries, this intelligence is also available in
> clients, thus allowing a "smart" client to merge updates from a "dumber"
> server.
>
> For data source developers there's no need to do anything manually to
> use and support capabilities, in contrast to OpenSync and the Funambol
> client library.
>
>   
Sorry I shouldn't have written that line. I don't know SyncEvolution.
It's your baby and mine is opensync. Nothing else to say.

-- 
/Bjoern Ricks

On Tue, 2009-10-20 at 09:55 +0200, Bjoern Ricks wrote:
> But as a developer of opensync I
> can say that our framework supports (nearly) all use cases already.

Do you support the use cases theoretically or in practice? My
understanding is that "vCard 2.1 (phone) <=> vCard 3.0 (Evolution)" does
not work. Nor does vCalendar <=> iCalendar. In my opinion the "future
proofness" of OpenSync is mostly theoretical at this point. I'd be happy
to be proven wrong, of course.

>  I
> don't think that SyncEvolution can handle different capabilities. 

This is incorrect. Please have a look at
http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard

It explains how the Synthesis engine uses capabilities to determine
which properties are supported by a peer and how it generates that
information automatically from the data format description. In contrast
to other SyncML libraries, this intelligence is also available in
clients, thus allowing a "smart" client to merge updates from a "dumber"
server.

For data source developers there's no need to do anything manually to
use and support capabilities, in contrast to OpenSync and the Funambol
client library.

-- 
Bye, Patrick Ohly
--  
Pat...@gm...
http://www.estamos.de/

On Mon, Oct 19, 2009 at 06:29:24PM +0200, Daniel Gollub wrote:
> Everytime when Björn or I disappear for some weeks the development is kind of 
> frozen.

Maybe it would help to go into more detail in what kind of development
exactly is still needed for 0.40.  Is there still a lot to do?  Or
rather just responding to bugs?

Once 0.40 is out, presumably the ball is in the hands of the plugin
writers and the core is in maintenance mode, until somebody steps up and
starts to do major changes (probably not you).

Michael

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

On Mon, 2009-10-19 at 22:44 +0100, Paul Eggleton wrote:
> 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,

At the risk of repeating myself: where is the merge and conflict
handling engine which takes device capabilities into account? I'm not
even sure whether the APIs are in place for it. The last time this came
up, it wasn't clear whether capabilities were format independent or tied
to a specific data format. Even if the APIs are defined and somewhat
documented, unless there's an implementation which does everything which
is needed, I consider the API experimental.

You've mentioned SyncEvolution below; I'm using that as an excuse to say
a bit more about it ;-)

> > - OpenSync has invented it's own protocol - though SyncML is also
> > supported via plugin.
> 
> I'm not sure what you mean.

I bet Henrik means the dataflow protocol. It handles exchanging change
information and item data, just like SyncML. It may be more flexible,
but it also has issues with timeouts (solved?) and handling "unusual"
batches of changes (SyncML, solved by removing timeouts?!). This is just
from reading what was said here on the list, my apologies if I
misunderstood the issues.

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

Not quite. With the SyncEvlution backend API, which is about as
difficult (or easy) as the datasource API in OpenSync, it is very easy
to write a SyncML client using SyncEvolution. The device or datasource
doesn't have to support SyncML. Once that is done and we have the
"personal SyncML server" working 1.0 (it already runs, but there are
also many known TODOs), then synchronization between that non-SyncML
datasource, the core databases and other datasources works.

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

Do you have a specific system in mind? In which way is it more complex
than SyncML such that it cannot be mapped to SyncML? Can it be mapped to
OpenSync semantics?

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

The good news perhaps (depending on how you decide to proceed) in this
discussion is that it doesn't have to be written from scratch. The
Synthesis engine exists, it solves all of the hard problems that are
missing in OpenSync [1].

The discussions earlier this year on the list and also in private with
Daniel + Michael (private because it was still confidential und
uncertain then whether Synthesis would go open source) was an attempt to
find out how that engine could have been used in OpenSync. I'm afraid
that this is quite a bit of work and not something that I could take on
and meet our goals (working SyncML client in Moblin 2.0). It's far
easier to take the existing Synthesis framework and build something
around it instead of shoehorning it into a different system, in
particular one where the key aspects (data handling) are unclear (to
me!).

I don't want to distract from the discussion around OpenSync, but if it
helps: I can promise that if there is an interest in switching the core
engine, then I'll do all I can to help salvage the parts which IMHO are
working (datasource plugins and the community which produced them) by
integrating them into SyncEvolution and making sure that they get
released. I haven't talked about this with my managers at Intel, but I'm
confident that they will support this, even if it means shifting some of
our schedule around.

[1] http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard

-- 
Bye, Patrick Ohly
--  
Pat...@gm...
http://www.estamos.de/

On Mon, 19 Oct 2009, Daniel Gollub wrote:
> So how should we solve the problem?
> Should i declare OpenSync as dead? 

If you ask me I don't think so. OpenSync still has too much promise and there 
has been too much work put into it already to just let it go. (Then again I am 
the one keeping a handheld environment alive that is still using Qt2 and is 
now over 7 years old (!) - so perhaps I am not the best person to ask :) 
Still, my statement stands.

> Or should i stop mainting the project and hand it over to someone else? 

Well that depends on someone being willing and able to step forward and do it. 
Myself, I'm not unwilling per se, but I don't feel sufficiently armed with the 
knowledge yet to fix many of the bugs that are open, and without that I 
wouldn't feel confident in being the maintainer. In any case I think the title 
is less important than people actually doing the work that needs to be done, 
whoever those people might be :)

> I want to suggest now that we _all_ should try something new:
> 
> We look for volunteers who are interested in becoming OpenSync core
> contributors and assign special components of the core to them.

The trend I have observed in open source projects is that most contributors 
are either driven by commercial needs (rare) or they are students with lots of 
spare time and enthusiasm. Actually I don't fall into either of these 
categories; I seem to have been able to preserve a lot of my spare time and 
enthusiasm even though I am out at work (perhaps because my daily work is not 
as stimulating as some of the open source projects that I get to work on); 
however I still think the latter group (students) is where we will find new 
recruits.

I think broadly though (and this is just restating what we have already been 
discussing) we just need to lower the barrier to entry for new people to get 
involved. Also I think that any project also has to work reasonably well (at 
least some part of it) for people to be enthusiastic about working on it - if 
it just seems like a bucket of bolts they may decide it's not worth their time 
or feel that they're not confident enough in their abilities to take it on.

> My role will be just kind of a mentor, and i just try to be available for
> question as much as possible and will do only developing and debugging if
> there is no pending questions from the other core developers.

That sounds great. If you can try to pass on some of your knowledge then 
hopefully the rest of us will be able to take some of the burden of assisting 
users and other developers. I guess if you will be in a position to answer 
people's questions as much as possible then you may need to consider how you 
can set a balance between this and your personal commitments. But that is a 
question for you of course :)

I'm not quite sure how to decide which areas I would work on in the core; as 
you say there is great temptation to take on the areas that are most important 
to me as a plugin developer. I agree though that that will ultimately not 
solve anything.

I have some hesitation in doing this, but perhaps if I can take these two 
items for now:

>  - Synchronization Engine (workflow of the Synchronization: connect,
>    get_changes, ...)
>    * documentation
>    * cleanup
>    * maintenance
>    * bugfixing
>    * profiling
>  - Format Conversion (abstract logic to convert formats, e.g. conversion
>    pathes, ...)
>    * review of the conversion path building process
>    * profiling
>    * documentation

I don't know if we have much time for profiling at the moment :) Bugfixes and 
understanding & documenting the process are a lot more important right now. I 
am still also ready to do fixes and completion of the API documentation in any 
of the areas required, but what I am usually lacking there is understanding 
about how some of the functions should work.

Cheers,
Paul

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.

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

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

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

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

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?

> 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

On Mon, 19 Oct 2009, Daniel Gollub wrote:
> > I just read a blog posting [1] by one of the Akonadi developers about
> > some discussions that have gone on at their recent meeting. It seems for
> > now they have given up waiting for OpenSync and are looking at
> > alternatives. This is extremely unfortunate - historically I would have
> > considered the Akonadi project to be one of OpenSync's strongest allies.
> 
> Thats not new to me ... the kde-pim and akonadi developers stated this
>  several times the last weeks/months. Not quite sure how many of them
>  really checked if this true or not ...

No, they probably didn't. But to be fair unless you're on the inside of our 
project it's hard to tell what the status of it is. Even we don't know a lot 
of the time :)

> But what they're doing is "just" moving KitchenSync and libqopensync to
> playground, which is a development branch AFAIK. Which sounds reasonable to
>  me ... so no reason to get panic.

Maybe not a reason to panic, but it is surely not a good sign.

> In fact things changed for me in mid September and last weeks very
> dramatically, in terms of spare time. But i still try to stick with the
> project and invest much as time as possible an reasonable. But private
>  things come first ... i hope you understand that.

Of course. One must always have priorities, and personal life must come first.

> So you're completely right - and I also have concerns about the very low
>  BUS- factor [1] we have for OpenSync core development. If I disappear for
>  a while OpenSync development trunk sometimes freezes. 

Bus factor, this is a new term to me, but it does describe our situation very 
well. This is indeed what I would hope to improve. I'll check your other mail 
and respond there as well.

Thanks,
Paul

On Mon, Oct 19, 2009 at 09:14:27PM +0200, Daniel Gollub wrote:
> Actually i planned to target also pool B - at least some of them.
> Do you see any chance that i get any of those?

I liked your topical list.  That kind of project breakdown is good for
anyone to get a mental handle on things.

But I can only talk from my own experience here, which is as part of
the team for the barry-sync plugin.

I don't really have time to read all the code in opensync, so I end up
focusing on the parts that pertain to me.  This ends up being the plugin
API, learning as I go, and the opensync_time.c functions, which I
started looking at back when I was trying to do timezone stuff correctly.
(Still haven't finished that in the barry-sync plugin.)

Also, I've been working a bit on the application side of the opensync API,
and I find little things there too.  If I can read the code and submit
a fix, I just go ahead and commit it.

So that's 3 areas that I'm interested in: plugin API, time functions, and
application side API.  But I don't have the time to volunteer to take
charge of any of them, only to contribute where I bump into issues.

So, while I consider myself in pool B, unfortunately I'm passing by
your list completely, since I'm not in pool A, and don't have the time
to take on any more responsibility.

Not sure if that answers your question...

- Chris

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

On Monday 19 October 2009 08:37:13 pm Chris Frey wrote:
> On Mon, Oct 19, 2009 at 06:29:24PM +0200, Daniel Gollub wrote:
> > I want to suggest now that we _all_ should try something new:
> >
> > We look for volunteers who are interested in becoming OpenSync core
> > contributors and assign special components of the core to them. There is
> > no deep knowledge in OpenSync core development required today ... just
> > the willing to help the OpenSync development and maybe some very basic C
> > programming is required (i leanred C also while programming on OpenSync
> > ... so don't hesistate to start here as well).
> 
> Continuing from my previous email in the other thread....
> 
> There are two pools of developers:
> 
> 	A) developers who have lots of free time and are looking for
> 		a project to significantly contribute to
> 
> 	B) developers who are solving their own problems and willing to
> 		help another project only so far as it helps them
> 
> Pool B is a whole lot bigger than pool A.
> 
> The above strategy only targets pool A.  We're publishing a list of bugs,
> and asking who wants to step up and fix them.

Actually i planned to target also pool B - at least some of them.
Do you see any chance that i get any of those?

[...]

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Hi,

I've just joined the mailing list and i'm reading this thread with a lot of 
interest. One can indeed be a little scared and overwhelmed by the 
complexity of the Opensync project, but after a deeper glance i can see 
thera are some clear goals to obtain, some nice background (code, 
documentation, etc) and of course proper people to do it.
I'll be observing the project for a while, since i'm gathering information 
for my master's thesis about synchronization, concerning Linux and CDC/CLDC 
devices :)

Go ahead, goog luck!

Bloosky
[Poland]

On Mon, Oct 19, 2009 at 06:29:24PM +0200, Daniel Gollub wrote:
> I want to suggest now that we _all_ should try something new:
> 
> We look for volunteers who are interested in becoming OpenSync core 
> contributors and assign special components of the core to them. There is no 
> deep knowledge in OpenSync core development required today ... just the 
> willing to help the OpenSync development and maybe some very basic C 
> programming is required (i leanred C also while programming on OpenSync ... so 
> don't hesistate to start here as well).

Continuing from my previous email in the other thread....

There are two pools of developers:

	A) developers who have lots of free time and are looking for
		a project to significantly contribute to

	B) developers who are solving their own problems and willing to
		help another project only so far as it helps them

Pool B is a whole lot bigger than pool A.

The above strategy only targets pool A.  We're publishing a list of bugs,
and asking who wants to step up and fix them.

Going with my suggestion (see other email on losing API stability)
targets both pools, since:

	- everybody is using the latest code

	- any bug that needs to be fixed, or feature that needs to be
		implemented, will be felt immediately

	- anyone who feels that need, will have the ability to scratch
		that itch immediately, and see their work released
		within a month, thereby solving both OpenSync's problem
		and their own in real time

One of those needs is documentation.  I think releasing 0.5x and dropping
API stability will help fix that too.

People need to be invested in the current code, not 0.22.  Right now,
0.22 doesn't solve their needs, and 0.4x is held up by artificial constraints,
so people are developing their own non-API-stable platforms.

- Chris

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

On Mon, Oct 19, 2009 at 06:39:01PM +0200, Daniel Gollub wrote:
> On Monday 19 October 2009 06:05:12 pm Henrik /KaarPoSoft wrote:
> > 
> > ----- oOo -----
> > 
> > So, here is a proposal:
> > 
> > Let's create a new project (called newSyncML? OpenSyncML? ???)
> [...]
> 
> I thought also about starting with OpenSync from scratch or so ... but this 
> would cause even more confusion and damage i guess - and it would also take 
> lots of time to get the same (basic) functionality we have today.

I agree with Daniel.

Starting over is why 0.4x is taking so long.  And that kind of "starting over"
was more of an API and refactoring in order to add new things like
capabilities, etc.  Starting from scratch is just that much worse of an idea,
in my opinion.

Writing a truly generic syncing library takes a lot of forethought, and
OpenSync has done the work to get this far.  Let's not abandon ship now.

In my opinion, one thing that could be done to speed up OpenSync development
is to change the release cycle, and the release priorities.  API backward
compatibility has been a set of handcuffs hindering progress.  When people
saw that 0.22 was undergoing a rewrite, and when they saw how long it
was starting to take, they (including me) put it on the mental back burner
until it was ready.  This mentality robbed OpenSync of input, and it left
responsibility for progress on the "other guy's" shoulders.

A radical idea: the day that 0.4x is released (which should be today),
it should be abandoned, and 0.5x should start.  0.40 would == 0.50.
But the goal of 0.5x would be to remain release-ready stable at all times.
It should be possible to checkout the latest SVN of the 0.5x tree,
and all documentation and functionality should be ready to go into
any distro.  Simple tarball releases of 0.50, 0.51, 0.52, etc would
happen automatically, almost scripted, every month.

The only guarantee that 0.5x would NOT make is API stability.  If an API
change breaks existing code, make note of it, bump the lib.so and the
include directory version numbers, and release right away, with a
porting note in the release announcement.

This breaks the work of staying current into small chunks.

Leave API stability for the 1.0 release.

We never want to get into this situation again, where people are clinging
to 0.22 because it is the only stable API.  Get rid of the stable API
promise until we're ready to actually deliver it.

- Chris

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

On Sun, 2009-10-18 at 23:53 +0100, Paul Eggleton wrote:
> I just read a blog posting [1] by one of the Akonadi developers about some 
> discussions that have gone on at their recent meeting. It seems for now they 
> have given up waiting for OpenSync and are looking at alternatives.

They were looking at writing a SyncML client based on the Funambol C++
client library and a SyncML server based on libsyncml. The former kind
of works, but has its limitations. The same limitations are the reason
why I switched from Funambol to libsynthesis. A server requires quite a
bit of logic which is not in libsyncml (by design!), so they didn't get
it to work.

I suggested that using libsynthesis and/or SyncEvolution [1] would solve
both of their problems and the consensus in September was that this was
worth a try. The guy working on the SyncML support was on vacation much
of last month, so we need to pick up that discussion again.

> For OpenSync to be successful it needs to become a stable, working 
> synchronisation platform that application developers (and users) can rely on. 
> I feel like we're about 90% there, but we need to finish the last 10% or all of 
> the work that has been done over the last few years will be mostly wasted.

After the discussions I was involved in earlier this year, my perception
is a bit different. All the hard problems (data merging + conversion)
were pushed out into plugins, but no-one is writing these plugins
(conversion vCard 2.1 -> 3.0, vCalendar 1.0 -> iCalendar 2.0). I also
have my doubts whether it is possible with the current APIs. I tried to
understand its design and but didn't get very far.

My own approach with SyncEvolution is different: start with working code
which solves these problems (the engine from Synthesis) and build a
complete solution around it. For those who haven't heard the news [2],
direct synchronization with one instance of SyncEvolution acting as
client and another instance acting as SyncML server is already possible.
We have SyncML/OBEX support almost implemented, so soon we'll be able to
try out local synchronization with SyncML capable phones.

I have ideas how this could be turned into a solution for other,
non-SyncML data sources. Basically I would do it like Henrik suggested:
use SyncML as the protocol between independent entities and writing
SyncML stubs for other data sources. But I don't want to use this list
for non-OpenSync discussions unless there is an explicit interest. I
wouldn't have posted here if you hadn't started questioning OpenSync
(and asked for alternatives) yourself.

[1] http://syncevolution.org/
[2] http://lwn.net/Articles/356712/

-- 
Bye, Patrick Ohly
--  
Pat...@gm...
http://www.estamos.de/

On Monday 19 October 2009 06:05:12 pm Henrik /KaarPoSoft wrote:
[...]

> OpenSync - if we ever deliver - would implement most of "my objectives",
> but:
> - will we ever deliver?

We'll see ;)

> - OpenSync has invented it's own protocol

Thats new to me ... which one?

> - though SyncML is also
> supported via plugin.

Right.

> - OpenSync will require custom-made plugins for each data source to be
> supported.

Right, that was always the idea of OpenSync ... since there are more porotcols 
out then SyncML ... thats acutally the only reason why OpenSync exists. If 
there would be only SyncML - we would only need something like libsyncml or 
fundambola or so ...

> - As witnessed by this mailing list, it seems that the OpenSync design
> is so complicated and poorly documented, that willing contributors are
> scared off.

Right - but these are things which can be fixed. You just need to start help 
getting things in shape ... e.g. start helping review documentating a 
component ...

JFYI, i didn't wrote most of the code ... and i didn't started the initial 
branch for the 0.3x tree ... i started with OpenSync  with relase 0.19 or 
so... and it scared me also several times .. it's very complicated - but even 
i managed to get familiar with it. It got complicated over time with the 
multiple (object) engines .. and the merger and capabilities stuff .. if you 
compare with 0.22 ... but this are things which are required for smooth 
syncing.

> 
> ----- oOo -----
> 
> So, here is a proposal:
> 
> Let's create a new project (called newSyncML? OpenSyncML? ???)
[...]

I thought also about starting with OpenSync from scratch or so ... but this 
would cause even more confusion and damage i guess - and it would also take 
lots of time to get the same (basic) functionality we have today.

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Hi,

we have a pretty low BUS factor [1] for OpenSync core development. Which is, i 
guess, the primary reason why the OpenSync development is so slow ...

Everytime when Björn or I disappear for some weeks the development is kind of 
frozen.

This is frustrating the OpenSync community ...

And for developers it's pretty hard to start with OpenSync core developer due 
to missing documentation or comments completely. So in the past Björn and I 
tried this:

We tried to fix all the tickets which are oustanding for the next development 
milestone. If there where any question from other developers we tried to 
answer them in time ... later thing didn't work as often as it should be. 
Especially if there were certain questions only I was able to reply ... and 
haven't, due to lack of time ... i'm sure i also missed some question to 
answer the last month, because i was so busy with private things that i was 
away from development for weeks.

So how should we solve the problem?
Should i declare OpenSync as dead? Or should i stop mainting the project and 
hand it over to someone else? If anyone thinks this would help ... please let 
me and the others know. Currently I'm certianly not the best choices as a 
maintainer due to the lack of time i can spent on this project. But maybe i 
still have some understanding how OpenSync in detail works, which could be 
very valuable to finally complete this project ...

I want to suggest now that we _all_ should try something new:

We look for volunteers who are interested in becoming OpenSync core 
contributors and assign special components of the core to them. There is no 
deep knowledge in OpenSync core development required today ... just the 
willing to help the OpenSync development and maybe some very basic C 
programming is required (i leanred C also while programming on OpenSync ... so 
don't hesistate to start here as well).

My role will be just kind of a mentor, and i just try to be available for 
question as much as possible and will do only developing and debugging if 
there is no pending questions from the other core developers.

Are there any volunteers for following components?

 - Application API
   * main objective: API review and keeping it stable
   * documentatoin
 - (Sync) Plugin API
   * main objective: API review and keeping it stable
    * documentation
 - Format Plugin API
   * main objective: API review and keeping it stable
   * documentation
 - Synchronization Engine (workflow of the Synchronization: connect, 
   get_changes, ...)
   * documentation
   * cleanup
   * maintenance
   * bugfixing
   * profiling
 - Format Conversion (abstract logic to convert formats, e.g. conversion 
   pathes, ...)
   * review of the conversion path building process
   * profiling
   * documentation
 - Mapping Logic (abstract logic to compare and map similar/same entries)
   * review of the logic
   * documentation
   * bugfixing
 - Capabilties, Merger and Demerger
   * completing capabilities merger/demerger implementation
   * documentation
 - IPC
   * maintenance
   * (porting work to different platforms)
   * documentation

The idea primary idea is not that you took the component you need to fix 
anyway because your plugin xyz is currently not working because of xyz. The 
primary idea is just to start to contribute to OpenSync core ... and since 
we're primarily lacking on documentation we should start with reviewing the 
code and document how things work .. to make it easier for other developers to 
understand and contribute code.

[1] http://en.wikipedia.org/wiki/Bus_factor

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

2005	Jan	Feb	Mar (9)	Apr (84)	May (18)	Jun (12)	Jul (6)	Aug (7)	Sep (10)	Oct (31)	Nov (59)	Dec (14)
2006	Jan (53)	Feb (15)	Mar (43)	Apr (40)	May (63)	Jun (142)	Jul (54)	Aug (31)	Sep (30)	Oct (39)	Nov (36)	Dec (64)
2007	Jan (128)	Feb (261)	Mar (156)	Apr (127)	May (76)	Jun (131)	Jul (83)	Aug (124)	Sep (83)	Oct (88)	Nov (180)	Dec (90)
2008	Jan (86)	Feb (93)	Mar (117)	Apr (104)	May (65)	Jun (35)	Jul (38)	Aug (111)	Sep (58)	Oct (33)	Nov (102)	Dec (194)
2009	Jan (193)	Feb (74)	Mar (111)	Apr (77)	May (31)	Jun (20)	Jul (1)	Aug (3)	Sep (57)	Oct (125)	Nov (50)	Dec (3)
2010	Jan (26)	Feb (5)	Mar (13)	Apr (3)	May (3)	Jun (12)	Jul (27)	Aug (47)	Sep (105)	Oct (53)	Nov (34)	Dec (21)
2011	Jan (115)	Feb (17)	Mar	Apr (6)	May (16)	Jun (15)	Jul (85)	Aug (21)	Sep (13)	Oct (12)	Nov (28)	Dec (23)
2012	Jan	Feb (13)	Mar (4)	Apr	May (1)	Jun (5)	Jul (5)	Aug (31)	Sep (8)	Oct	Nov	Dec (1)
2013	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug (33)	Sep (9)	Oct (10)	Nov (2)	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec (4)
2016	Jan (2)	Feb	Mar (3)	Apr	May (3)	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec

opensync-devel Mailing List for OpenSync (Page 39)

opensync-devel — The place to coordinate the development of OpenSync