Menu
▾
▴
opensync-devel
|
From: Paul E. <blu...@bl...> - 2009-10-18 22:53:32
|
Hi all, I think it's plain to everyone that as a project we have a serious problem. Things are not moving forward at the pace that we really need them to and have not been for quite some time, and this fact has not gone unnoticed by the wider community. Every day people complain about the lack of decent synchronisation support in open source products, so there is definitely great demand - and yet OpenSync is still not ready to solve the problem. 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. Now, I recognise that many of us (especially me) have not contributed much to the core of OpenSync. The problem there at least from my perspective is that few of us have enough information about the vision behind the OpenSync core or its internals in order to contribute effectively to it - most of the responsibility these days falls on Daniel to answer any questions or to make decisions. Daniel, I do recognise that you don't have as much time to work on OpenSync as you used to, and nobody would blame you for that; however if the project is to go forward then something has to change. 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. I myself stand fully ready to get involved more closely, but I need guidance - documentation that covers the design foremost. In a number of areas I would just need a few pointers on where to look, some commentary on how things are supposed to work etc. and then I can fill in the blanks and write full documentation. Armed with more information about OpenSync's inner workings, perhaps more people can help solve the remaining issues and finally get a stable release out there. Let's get back on track! Cheers, Paul [1] http://www.omat.nl/2009/10/17/akonadi-meeting-day-1-discussions-api- review/ |
|
From: Martin O. <doc...@gm...> - 2009-10-19 12:35:35
|
Hey Paul, Perhaps the problem is that the opensync project has attempted to solve too many problems in the same framework? * Data Access * Data Formating * Synchronisation Logic It would have probably have been a better idea if each of those problems had been solved separately but in ways that made them core components to the operating systems and perhaps in ways that made their extension trivial. Ubuntu still does not ship with any synchronisation functionality because compounding all problems into one project has made the entire thing a huge non-trivial problem. But perhaps it's too late now, I'm resined to the fact that I will never have good sync support and that every front end app will have poorly written data access, formating and syncing and the OS will never have anything definitive. Why are we trying to solve these problems? was it wise to write something that needed to be rewritten several times, whilst supporting obsolete versions and fracturing development effort and sapping the will of extension developers? I question the choices made in this project. Martin |
|
From: Henrik /K. <kaa...@us...> - 2009-10-19 16:05:34
|
Dear all, Three or four years ago I developed a piece of software - NokSync - to sync Mozilla to a Nokia mobile phone. See http://www.kaarposoft.dk/noksync/ Users seemed to be quite happy with it! And so was I... NokSync works only on windows and only with older versions of Nokia PC Suite. So, two years ago I switched to Linux, and wanted to do the same. OpenSync seemed like the perfect platform for this. However, now - after two years - it still does not work... OpenSync 0.40 seems just around the corner, but so it did 6 months ago, and 12 months ago. So, I am taking a step back and asking myself: What are we trying to accomplish? ----- oOo ----- 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). Use Case: I have a mobile phone, a GMail account, and a local Thunderbird installation. I want to keep those three in sync from my Linux or Windows desktop. So, I ask myself: How can/should this be done? What we need is: 1) A desktop application. 2) A protocol between the desktop app and each data source. 3) Capabilities in each data source to use the protocol. Where (1) should maybe be extended to: 1a) Several desktop applications (KDE, GTK, Windows, ...) 1b) Plugins for existing local applications (KDE Pim, Thunderbird, ...) to provide an application-centric GUI 1c) A library for (1a) and (1b) to use As for (2) - a protocol - I really only see one "standard" choice out there: SyncML. So we could invent our own protocol (like in OpenSync) or stick to the "standard" SyncML. Regarding (3): Most mobile phones have SyncML capabilities. Plugins exists for many applications to provide SyncML in one way or another - not all directly suited to our needs, but most could be used as building stones. ----- oOo ----- Funambol seems to be a successful solution to sync issues, and has native support or plugins for a multitude of devices and applications. However, it deviates from "my objective" in one important way: it is based on a central server. Devices / applications sync towards this central server. You could implement such a sever on your own desktop (Funambol provides open sources for this), but sync would still be initiated by a device/application and sync towards one central database. ----- oOo ----- OpenSync - if we ever deliver - would implement most of "my objectives", but: - will we ever deliver? - OpenSync has invented it's own protocol - though SyncML is also supported via plugin. - OpenSync will require custom-made plugins for each data source to be supported. - As witnessed by this mailing list, it seems that the OpenSync design is so complicated and poorly documented, that willing contributors are scared off. ----- oOo ----- So, here is a proposal: Let's create a new project (called newSyncML? OpenSyncML? ???) In this project, let's develop A) a library for SyncML synchronization B) one or more desktop applications using (A) C) one or more plugins for existing applications - using (A) D) a library helping to develop a SyncML server for "any data-source" E) plugins / applications / whatever for different data-sources to act as SyncML servers - possibly using (D) (A) would mainly have to deal with data comparison and anchors and GUID/LUID mappings. ----- oOo ----- Daniel and others, I am sorry, but this is really a call for "Don't throw good money after bad". I am considering whether OpenSync is really the way to go for "my objectives", and more and more it looks like a no... What do you all think about this proposal? /Henrik Martin Owens wrote: > Hey Paul, > > Perhaps the problem is that the opensync project has attempted to solve > too many problems in the same framework? > > * Data Access > * Data Formating > * Synchronisation Logic > > It would have probably have been a better idea if each of those problems > had been solved separately but in ways that made them core components to > the operating systems and perhaps in ways that made their extension > trivial. > > Ubuntu still does not ship with any synchronisation functionality > because compounding all problems into one project has made the entire > thing a huge non-trivial problem. > > But perhaps it's too late now, I'm resined to the fact that I will never > have good sync support and that every front end app will have poorly > written data access, formating and syncing and the OS will never have > anything definitive. > > Why are we trying to solve these problems? was it wise to write > something that needed to be rewritten several times, whilst supporting > obsolete versions and fracturing development effort and sapping the will > of extension developers? > > I question the choices made in this project. > > Martin > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel > > |
|
From: Jakub M. <ja...@o2...> - 2009-10-19 19:04:24
|
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] |
|
From: Paul E. <blu...@bl...> - 2009-10-19 21:44:17
|
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 |
|
From: Patrick O. <pat...@gm...> - 2009-10-20 05:36:21
|
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/ |
|
From: Bjoern R. <bjo...@go...> - 2009-10-20 07:55:54
|
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 |
|
From: Patrick O. <pat...@gm...> - 2009-10-20 08:12:06
|
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/ |
|
From: Bjoern R. <bjo...@go...> - 2009-10-20 08:49:58
|
> 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 |
|
From: Henrik /K. <kaa...@us...> - 2009-10-20 16:29:20
|
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 |
|
From: Daniel G. <go...@b1...> - 2009-10-19 15:53:32
|
On Monday 19 October 2009 12:53:13 am Paul Eggleton wrote: [...] > I think it's plain to everyone that as a project we have a serious problem. > Things are not moving forward at the pace that we really need them to and > have not been for quite some time, and this fact has not gone unnoticed by > the wider community. Every day people complain about the lack of decent > synchronisation support in open source products, so there is definitely > great demand - and yet OpenSync is still not ready to solve the problem. Ack. > > 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 ... 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. But it's funny to see that Sascha Peilicke is commenting here ... you might remember him from the past when he complained about the glibc dependency of libsyncml ... (i still hope he mixed that up with glib ;)) > > Now, I recognise that many of us (especially me) have not contributed much > to the core of OpenSync. The problem there at least from my perspective is > that few of us have enough information about the vision behind the > OpenSync core or its internals in order to contribute effectively to it - > most of the responsibility these days falls on Daniel to answer any > questions or to make decisions. Right. > Daniel, I do recognise that you don't have > as much time to work on OpenSync as you used to, and nobody would blame > you for that; however if the project is to go forward then something has > to change. 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. 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. Maybe instead of concentrating on getting 0.40 out ASAP, i should try to get rid of this low BUS factor ... and concentrate on helping developers to start with core development primarily. I tried this now and then .. and succeed in some cases - e.g. Björn. But he has also limited spare time, like all of us. So we need more core developers to solve this problem. To bring this BUS factor high enough to speed up the trunk development in OpenSync core ... Since i had the entire day to think about an solution, I'll come up with a new plan to address this BUS factor problem - in a separated mail. [...] > I myself stand fully ready to get involved more closely, but I need > guidance - documentation that covers the design foremost. In a number of > areas I would just need a few pointers on where to look, some commentary > on how things are supposed to work etc. and then I can fill in the blanks > and write full documentation. Armed with more information about OpenSync's > inner workings, perhaps more people can help solve the remaining issues > and finally get a stable release out there. Thanks for your contribution and volunteering for core development ... > > Let's get back on track! Right, let's start ... [...] [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 |
|
From: Paul E. <blu...@bl...> - 2009-10-19 21:05:34
|
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 |
|
From: Daniel G. <go...@b1...> - 2009-10-19 16:00:54
|
Hi Martin, long time no see ... On Monday 19 October 2009 02:27:38 pm Martin Owens wrote: > Perhaps the problem is that the opensync project has attempted to solve > too many problems in the same framework? > > * Data Access > * Data Formating > * Synchronisation Logic > Thats wrong - OpenSync actually only addresses: "Synchronisation Logic" Data Access and Formating is done by plugins. And they actually should use libraries which have special formats or protocol implemented to convert a format or access a device to gather/write data. e.g.: - palm-sync is using pilot-link / pisock - barry-sync is using the barry library - syncml obex plugin is using libsyncml, which is also using libopenobex The only "data access" relevant thing in OpenSync are the plugin API calls. The only data formating calls are the format plugin API calls. There is no complex code inside OpenSync addressing this. If there is one day a project doing perfect data formating of PIM data or any other data, there will be a OpenSync format plugin on the next day ... we don't have to change a single line in OpenSync core to make use of something a plugin like this ... 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 |
|
From: Daniel G. <go...@b1...> - 2009-10-19 16:39:20
|
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 |
|
From: Chris F. <cd...@fo...> - 2009-10-19 18:23:40
|
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. |
|
From: Patrick O. <pat...@gm...> - 2009-10-19 18:14:47
|
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/ |
|
From: Martin O. <doc...@gm...> - 2009-10-21 05:13:13
|
Hey Daniel, Good to see you, On Mon, 2009-10-19 at 18:00 +0200, Daniel Gollub wrote: > On Monday 19 October 2009 02:27:38 pm Martin Owens wrote: > > Perhaps the problem is that the opensync project has attempted to solve > > too many problems in the same framework? > > Thats wrong - OpenSync actually only addresses: "Synchronisation Logic" > > Data Access and Formating is done by plugins. That's all very interesting in theory, but is not my point. Plugins are by their nature 'a part of the framework'. While they are not part of your codebase, they are a part of the execution flow and thus you have device access, data access, formatting filtering and then synchronization logic as part of the opensync framework. Consider this instead: > And they actually should use > libraries which have special formats or protocol implemented to convert a > format or access a device to gather/write data. There is a shift from opensync plugins, all of which become deprecated. Towards DeviceKit and Services file system plugins. This mates device access and user online status with data access and provides a method for all kinds of scripting and hacking on the resulting data that they output (as files! how very unix). I would expect each plugin to try and express it's data in a way that is more direct, without too much filtering if it can be helped. But if it turns out to be easier to output clean FreeDesktop.org or LSB vcards, then so be it. Otherwise some filtering programs, standard stuff. Data goes in, data comes out cleaner. Now here comes the fantastic part, you don't have to care where you get your data from for syncing. It should be possible to just point opensync at two directories full of vcards and have it do it's thing. If that is all your program is doing, it makes the job fairly trivial to program and test for. Version 1.0 blam, done, out the door and we can all go home and have some crumpets. I know it's not a popular idea to make certain things part of the systematics of the operating system. But this is the best way to access data and sync it, leaving the door open to the user so she can customise how she wants to access the data if she wants. And if your wondering about online services or local EDS/KDE-PIM access, same rules apply. Just remember to use the services plugin system for online. Regards, Martin Owens |
|
From: Patrick O. <pat...@gm...> - 2009-10-23 05:13:34
|
On Wed, 2009-10-21 at 01:12 -0400, Martin Owens wrote: > output clean FreeDesktop.org or LSB vcards Have these two bodies standardized extensions to vCard 2.1/3.0? Do you have a pointer to that? -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
|
From: Martin O. <doc...@gm...> - 2009-10-23 11:56:15
|
On Fri, 2009-10-23 at 07:13 +0200, Patrick Ohly wrote: > On Wed, 2009-10-21 at 01:12 -0400, Martin Owens wrote: > > output clean FreeDesktop.org or LSB vcards > > Have these two bodies standardized extensions to vCard 2.1/3.0? Do you > have a pointer to that? > As far as I know they haven't, wouldn't it be nice if they had though. Forgive me if I made it sound like they had already, some of these problems are standards problems and can only really be solved with RFC or similar in the right bodies. Martin, |
Thanks for helping keep SourceForge clean.
X