Menu
▾
▴
opensync-devel
|
From: Patrick O. <pat...@gm...> - 2011-01-03 13:33:02
|
Hello OpenSync project! As you know, I have been watching your project for a while, before and in parallel to working on SyncEvolution. I've explained my motivation to work on SyncEvolution already (different architecture, build something in incremental steps, release usable code often), so I won't repeat that here. In this email I'd like to appeal to the OpenSync developers to reconsider whether keeping OpenSync around really helps Linux and open source syncing. My impression is that all efforts to put the project back on track have failed. I also think that they'll continue to fail, because the design is too complex. Michael has already published his thoughts on that when he announced that he would step down as maintainer of the SyncML plugin, and I have little to add to that. In the meantime, new developers show up who want to help. Some of them, like Emanoil, put in significant effort that doesn't benefit anyone because the rest of the system still doesn't work. There are precious few developers who still care about syncing; IMHO spending their time on OpenSync weakens other projects who still have a chance of solving the problem as a true open source project. Of course I am thinking of SyncEvolution here. It already works very well for SyncML. I also have support for additional protocols, which I will be able to publish soon. I think it would be worthwhile successor of OpenSync, but obviously I'll need help to cover all the use cases that you were shooting for with OpenSync. In case you wonder about Buteo: I have done an extensive analysis of it and can assure you that it is not a replacement for the Synthesis engine + SyncEvolution, by design. For example, it does not include data conversion support. The existing open source plugins are merely examples that are meant to be modified by anyone who wants to support a specific peer. Who is doing that work for the open source part is currently open (see bugs.meego.com #5468). Direct synchronization with phones isn't even meant to be a supported feature yet (not requested for meego.com). So my proposal is this: * officially declare OpenSync dead, to avoid distracting new developers and users * point towards SyncEvolution as an alternative * work with me on improving SyncEvolution so that it fits your needs; we could meet at FOSDEM this year to have a face-to-face meeting about next steps or meet online earlier I considered writing this as an open letter, but rejected the idea because I didn't want to make OpenSync look bad in public. Please let me know what you think. Disclaimer: I will not gain anything from expanding the scope of SyncEvolution. Quite the opposite, I expect to have a lot more work at my hands if you accept. So if you want to do me a favor, reject the proposal ;-} -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
|
From: Patrick O. <pat...@gm...> - 2011-01-03 13:40:32
|
On Mo, 2011-01-03 at 14:32 +0100, Patrick Ohly wrote: > I considered writing this as an open letter, but rejected the idea > because I didn't want to make OpenSync look bad in public. Please let me > know what you think. ... but then Daniel encouraged me to send it publicly. I meant to explain that, but then forgot to edit this paragraph when resending. -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
|
From: Daniel G. <go...@b1...> - 2011-01-03 13:48:20
|
On Monday, January 03, 2011 02:40:21 pm Patrick Ohly wrote: > On Mo, 2011-01-03 at 14:32 +0100, Patrick Ohly wrote: > > I considered writing this as an open letter, but rejected the idea > > because I didn't want to make OpenSync look bad in public. Please let me > > know what you think. > > ... but then Daniel encouraged me to send it publicly. I meant to > explain that, but then forgot to edit this paragraph when resending. Thank you for sending it publicly! -- Daniel Gollub Linux Consultant & Developer Tel.: +49-160 47 73 970 Mail: go...@b1... B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 |
|
From: Graham C. <g+o...@co...> - 2011-01-03 17:14:23
|
On Monday 03 January 2011 13:32:52 Patrick Ohly wrote: > In this email I'd like to appeal to the OpenSync developers to > reconsider whether keeping OpenSync around really helps Linux and open > source syncing. Patrick, Thanks for your well considered thoughts. I am a small (although fairly long term) contributor to OpenSync, and I have no particular desire to continue it if it is not going to be successful or there is a better alternative. Of course, I realise there are others who have invested much more time and effort than I have, for which I am extremely grateful, and who may feel much more strongly about it than I do. Speaking personally, my desire is to be able to synchronise my various devices and services, which include SyncML devices (of various flavours, each with their own quirks, bugs and features), GPE (which I continue to support), KDE (kontact) and Outlook/Exchange (for which I have limited, one-way support using flat files and OWA). I am happy to contribute to a project which has a reasonable prospect of supporting those various devices. I have learnt, over the years, that syncing is much harder than it appears at first sight! I will admit that I no longer fully understand the OpenSync architecture and design so I can't really comment on your view that it is too complex and will not achieve its goals. I do feel that the plugin API, and the format convertors, seem to be largely useful. Certainly for the GPE plugin it is not too hard to implement the required API and it seems to include pretty much the things that are likely to be required. I suspect that both discovery and capabilities may be over- complex, and I also think the flow-control (memory usage, timeout) problem is still not solved (which is partly my fault as I tried to solve it!). But the basic plug-in architecture seems useful and I do wonder whether any of it could be re-used. > Of course I am thinking of SyncEvolution here. It already works very > well for SyncML. I also have support for additional protocols, which I > will be able to publish soon. I think it would be worthwhile successor > of OpenSync, but obviously I'll need help to cover all the use cases > that you were shooting for with OpenSync. I do not have a good feel for what SyncEvolution can and cannot do: can you provide more information? One thing is the device access protocols, of course, but even if we all joined you and helped implement those, how would SyncEvolution compare with what OpenSync is intended to do? For example, does it only handle pair-wise sync? If so, what is the implication of that restriction (do you have to designate one of your devices as master and sync everything else to it)? Does it handle devices that have bugs or limited implementations (issues like capabilities and merging)? What about missing unique IDs? Conflicts? And the many other issues that OpenSync has been adding complexity while trying to solve? In summary, I would like to understand why you feel that redirecting our efforts to SyncEvolution has any greater chance of success in solving the hard problems of syncing. By the way, I do agree with your analysis of Buteo -- at the MeeGo summit it became clear that Buteo is not trying to solve the sync problem, it is more like a scheduler and manager. Graham |
|
From: Chris F. <cd...@fo...> - 2011-01-03 21:05:49
|
On Mon, Jan 03, 2011 at 02:32:52PM +0100, Patrick Ohly wrote: > Of course I am thinking of SyncEvolution here. It already works very > well for SyncML. I also have support for additional protocols, which I > will be able to publish soon. I think it would be worthwhile successor > of OpenSync, but obviously I'll need help to cover all the use cases > that you were shooting for with OpenSync. My personal opinion is that the steps of your proposal are just slightly backwards. I think that before we declare anything dead, that the replacement should first be just as much alive. Alive in the sense of features. Otherwise people will just continue hacking on the design they like best. So I'm also interested in the answers to Graham Cobb's questions. If there is something that OpenSync can do today that SyncEvolution can't, then that should be fixed before OpenSync dies. The project that is most useful and supports all useful features is the one that deserves to keep going. But in the meantime, I don't believe there is any harm in having both. It's the Linux way. :-) In other words, if you want the support of the OpenSync developers (such as it is), implement OpenSync's features in SyncEvolution (and maybe even change the name, since it sounds overly linked to Evolution syncing) and you'll win automatically. You won't need proposals. You'll have the features, and therefore the users *and* the developers. - Chris |
|
From: Patrick O. <pat...@gm...> - 2011-01-03 21:44:01
|
On Mo, 2011-01-03 at 16:05 -0500, Chris Frey wrote:
> On Mon, Jan 03, 2011 at 02:32:52PM +0100, Patrick Ohly wrote:
> > Of course I am thinking of SyncEvolution here. It already works very
> > well for SyncML. I also have support for additional protocols, which I
> > will be able to publish soon. I think it would be worthwhile successor
> > of OpenSync, but obviously I'll need help to cover all the use cases
> > that you were shooting for with OpenSync.
>
> My personal opinion is that the steps of your proposal are just slightly
> backwards. I think that before we declare anything dead, that the
> replacement should first be just as much alive.
Is OpenSync 0.4x alive today or vaporware? Is it recommended for
production use?
Is OpenSync 0.22 alive and supported? I know that it works for some
users and clearly SyncEvolution is no alternative to those users unless
it implements the same features.
> So I'm also interested in the answers to Graham Cobb's questions.
That deserves a more in-depth reply. I'll do that tomorrow.
> The project that is most useful and supports all useful features is
> the one that deserves to keep going. But in the meantime, I don't
> believe there is any harm in having both. It's the Linux way. :-)
The harm is that in the end, we end up with no project that really has
the desired features.
> In other words, if you want the support of the OpenSync developers
> (such as it is), implement OpenSync's features in SyncEvolution
Here's the catch: without support from additional developers, some
things will never get implemented because there are areas that I myself
cannot or do not want to support (for example, devices that I don't
have). GPE is one example. Akonadi another. I already wrote a prototype
backend for Akonadi, but now need a developer who is motivated to finish
and maintain it.
If everything already works and is implemented, why should I still want
the support of the OpenSync developers? Clearly your skills would be
wasted when focusing exclusively on maintenance.
> (and maybe even change the name, since it sounds overly linked to
> Evolution syncing)
I considered a name change, but rejected the idea because SyncEvolution
already had a good page ranking and was well-known under that name at
the time. I'm still reluctant to change it - too much uses the name
(domain, command line tool). But if a name change is considered crucial
despite the new interpretation of it ("the missing link"), then we can
discuss it.
> and you'll win automatically. You won't need
> proposals. You'll have the features, and therefore the users *and*
> the developers.
So far I have plenty of users, but only one additional developer (Ove
Kaaven, for the N900 port). I can only speculate about the reasons, but
I guess one of them is that OpenSync is still seen as the future for
syncing on Linux. I hesitate to describe it with such a slightly
disparaging comparison, but it is a bit like a honeypot that attracts
new developers who then get stuck without ever getting nearer to a
stable release of their work.
--
Bye, Patrick Ohly
--
Pat...@gm...
http://www.estamos.de/
|
|
From: Chris F. <cd...@fo...> - 2011-01-03 22:18:55
|
On Mon, Jan 03, 2011 at 10:43:52PM +0100, Patrick Ohly wrote:
> Is OpenSync 0.4x alive today or vaporware? Is it recommended for
> production use?
>
> Is OpenSync 0.22 alive and supported? I know that it works for some
> users and clearly SyncEvolution is no alternative to those users unless
> it implements the same features.
I'm not claiming that OpenSync is Hot Stuff. I think its ideas are,
but the implementation still needs work.
What I'm trying to say is that before someone tries to kill OpenSync,
maybe the replacement should be Hot Stuff. And if the replacement is
already Hot Stuff, then OpenSync will die of its own accord.
> > The project that is most useful and supports all useful features is
> > the one that deserves to keep going. But in the meantime, I don't
> > believe there is any harm in having both. It's the Linux way. :-)
>
> The harm is that in the end, we end up with no project that really has
> the desired features.
There are lots of splits in the Linux world, and they can all be seen
as harmful in some way. But that's how the free software world tends to
work. I know, because even my own rather niche project has a competitor
(Barry and XmBlackBerry). In the end, the world is a richer place
because users can choose which one works better for them. The project
that works the hardest will get the farthest.
Whether OpenSync or SyncEvolution remains is beside the point.
In the last few months I haven't had time to work on OpenSync as I
would have liked, and so I wouldn't have been able to work on
SyncEvolution either. Until one or both are able to clearly accomplish
the desired goals of syncing, both should remain.
If SyncEvolution turns out to be the winning project, more power to you!
Honestly. :-) But doing that organically is the more stable path.
(I don't like using the term "winning", but we're talking about
projects that should be alive or dead too, so I think it's fair.)
> Here's the catch: without support from additional developers, some
> things will never get implemented because there are areas that I myself
> cannot or do not want to support (for example, devices that I don't
> have). GPE is one example. Akonadi another. I already wrote a prototype
> backend for Akonadi, but now need a developer who is motivated to finish
> and maintain it.
>
> If everything already works and is implemented, why should I still want
> the support of the OpenSync developers? Clearly your skills would be
> wasted when focusing exclusively on maintenance.
I don't think that "It supports Akonadi!" is the feature I'm talking
about. That matters for end users, but for developers who have invested
in OpenSync, what matters is that the future flexibility is there,
and that the same edge cases that OpenSync has planned for are planned
for in SyncEvolution.
So in that sense, it is the SyncEvolution "engine" that must compete
with the OpenSync "engine." If both engines are theoretically capable
of supporting the same features, then it's just a matter of picking
the side with the most momentum. If you can prove that, you'll have
a much easier time of killing OpenSync.
But to my understanding, there are theoretical engine differences
that need to be analyzed and thought about. Does that make sense?
And I think Graham Cobb's questions were moving in that direction.
(Perhaps more profitably than my 2 cents.) :-)
> > (and maybe even change the name, since it sounds overly linked to
> > Evolution syncing)
>
> I considered a name change, but rejected the idea because SyncEvolution
> already had a good page ranking and was well-known under that name at
> the time. I'm still reluctant to change it - too much uses the name
> (domain, command line tool). But if a name change is considered crucial
> despite the new interpretation of it ("the missing link"), then we can
> discuss it.
Well, I *should* know better, but I'm still discounting it in my head
by habit, because OpenSync from the beginning has aimed for Everything(TM),
while the name of SyncEvolution ties it to one small platform.
This is just an impression level issue, and has nothing to do with
what SyncEvolution can actually do. But maybe users and developers
are getting that same impression?
Truth and clarity are more important than page rank, I think.
Page rank will follow.
> So far I have plenty of users, but only one additional developer (Ove
> Kaaven, for the N900 port). I can only speculate about the reasons, but
> I guess one of them is that OpenSync is still seen as the future for
> syncing on Linux. I hesitate to describe it with such a slightly
> disparaging comparison, but it is a bit like a honeypot that attracts
> new developers who then get stuck without ever getting nearer to a
> stable release of their work.
Honesty is the best policy. :-) You could be right.
- Chris
|
|
From: Emanoil K. <del...@ya...> - 2011-01-04 18:30:55
|
Hi,
I need to catch up with the thread, but for now I want to answer to this here
--- On Mon, 1/3/11, Patrick Ohly <pat...@gm...> wrote:
> have). GPE is one example. Akonadi another. I already wrote
> a prototype
> backend for Akonadi, but now need a developer who is
> motivated to finish
> and maintain it.
>
If you give me access to the code I could fix it, as I am highly motivated to have KDE4 sincable in near future (until someone fixes the rest of opensync).
For the rest I wish opensync could develop further, exactly because of its design - but I hope I'll answer later to the proper thread.
regards
|
|
From: Patrick O. <pat...@gm...> - 2011-01-04 09:04:53
|
Hello! Let me add the SyncEvolution list, because the technical information may be relevant. For those who see this for the first time, it started with an open letter that I sent to the OpenSync list asking whether it really still makes sense to continue with two different projects instead of focusing on one: http://sourceforge.net/mailarchive/forum.php?thread_name=20110103221846.GA21876%40foursquare.net&forum_name=opensync-devel I was suggesting that SyncEvolution has the better baseline to continue from. Of course this requires further explanation, which this email is about. It is in reply to Graham because he raised several interesting technical questions. On Mo, 2011-01-03 at 16:57 +0000, Graham Cobb wrote: > On Monday 03 January 2011 13:32:52 Patrick Ohly wrote: > > In this email I'd like to appeal to the OpenSync developers to > > reconsider whether keeping OpenSync around really helps Linux and open > > source syncing. > > Patrick, > > Thanks for your well considered thoughts. [...] > > Of course I am thinking of SyncEvolution here. It already works very > > well for SyncML. I also have support for additional protocols, which I > > will be able to publish soon. I think it would be worthwhile successor > > of OpenSync, but obviously I'll need help to cover all the use cases > > that you were shooting for with OpenSync. > > I do not have a good feel for what SyncEvolution can and cannot do: can you > provide more information? One thing is the device access protocols, of > course, but even if we all joined you and helped implement those, how would > SyncEvolution compare with what OpenSync is intended to do? SyncEvolution has grown organically over time (one could call it evolutionary...), instead of shooting for a grand design covering everything, like OpenSync did for 0.40. The main advantage is that there have been regular stable releases since the very beginning four years ago. On the other hand, features for which there was no real need yet are still missing. There have been different phases: 1. SyncML client for Evolution 2. SyncML client for additional storages (iPhone, Mac OS X, file) 3. backends contributed by external developers (Ove Kaaven: N900 calendar, Franz Knipp/m-otion.com: XMLRPC) 4. SyncML server (direct syncing with phones), both via Bluetooth and HTTP, using the Synthesis engine 5. non-SyncML protocols The last point is the goal for SyncEvolution 1.2, in development right now. It still uses the Synthesis engine and everything that it provides (data conversion, conflict handling). SyncML is also still in use, but only as internal protocol between two peers. What a developer above the engine sees is the storage plugin (aka data source) interface. Conceptually such a plugin must provide: 1. change tracking (otherwise only slow syncs work) 2. data import/export, either in the internal Synthesis format (field list) or in a backend specific text format that the engine understands Further references: * introduction to the Synthesis engine and its data conversion: http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard * convenience class for a data source which has id + revision string for each item and exchanges data as text: http://meego.gitorious.com/meego-middleware/syncevolution/blobs/master/src/syncevo/TrackingSyncSource.h * base class with maximum freedom: http://meego.gitorious.com/meego-middleware/syncevolution/blobs/master/src/syncevo/SyncSource.h * fully functional example backend: http://meego.gitorious.com/meego-middleware/syncevolution/trees/master/src/backends/file * configuration handling: http://syncevolution.org/development/configuration-handling * communication patterns and server mode: http://syncevolution.org/development/direct-synchronization-aka-syncml-server * local sync: http://www.mail-archive.com/syn...@sy.../msg01419.html Ove and Franz were able to implement their backends with very little assistance, so the documentation can't be that bad, although there's no doubt that documentation could always be better. > For example, does it only handle pair-wise sync? If so, what is the > implication of that restriction (do you have to designate one of your devices > as master and sync everything else to it)? Yes, sync is always between two peers. One storage should be the designated "master" copy of the data. Any data which cannot be stored by that "master" will get lost. The master could be in a capable system like EDS or Akonadi, or in the file backend, which can store anything that the sync engine itself can handle. A sync topology is created by defining several of these 1:1 relationships. The master itself might be the client of another server, as long as there are no loops. There is currently no logic for keeping several of these peers in sync, but that could be added at a meta level (keep syncing until all changes have been distributed). Unknown extensions are currently dropped. This could be changed, but leads to additional questions that would need to be sorted out: should such extensions be sent to all peers, or just the one who created them? What if different peers have a different understanding of "X-FOOBAR"? It is safer to limit syncing to the data that is fully understood and modeled in the Synthesis configuration file. Currently this covers vCard 3.0 + extensions and iCalendar 2.0 (including UID + RECURRENCE-ID, VTIMEZONE, VALARM, but not attachments). > Does it handle devices that have bugs or limited implementations (issues like > capabilities and merging)? Yes. The Synthesis engine has dealt with that for 10 years and contains a large collection of tools that can be used to deal with such problems, ranging from different data profiles to a full scripting language that can modify data on-the-fly. The Synthesis engine uses capability descriptions to determine which properties are supported by an unknown peer and has smart merging techniques for individual properties. For example, consider the case where a VEVENT was modified like this: 1. event in sync on peer A and B 2. DESCRIPTION is extended on peer A 3. SUMMARY is modified on peer B 4. syncing recognizes the conflict and resolves it by using the SUMMARY of peer B (because the item on B is more recent) and the DESCRIPTION of A (because the description of B is a subset of it) These two properties are handled differently because the conflict resolution policy is configured differently to reflect the difference between single-line and multi-line text. > What about missing unique IDs? In such a case only slow syncs are possible. The Synthesis data modeling defines which properties are compared to find pairs. The drawback of a slow sync is that data removed on one side will be recreated. I have thought a bit about that over Christmas, because I am now in that situation: I can modify the address book on my FRITZ!Box 7390 router, but it is an XML file with no unique identifier for each entry. My idea is to do synchronization in multiple steps: 1. keep a local mirror of all contacts 2. do a slow sync against that mirror to find pairs; items in the mirror which have no corresponding entry on the router can be removed 3. two-way sync between the mirror and my master data 4. upload copy of the mirror to the router The simpler alternative would be to pick some properties and use those as key, perhaps with hashing to keep the key size small. > Conflicts? See above. Client-wins/server-wins/most-recent-wins are all configurable. SyncEvolution itself uses most-recent-wins, with smart merging of some properties. > And the > many other issues that OpenSync has been adding complexity while trying to > solve? We would need to list those, but I'm fairly sure that much of it has been considered already. > In summary, I would like to understand why you feel that redirecting our > efforts to SyncEvolution has any greater chance of success in solving the hard > problems of syncing. My own summary, more at a meta level than the details above: * don't reinvent the wheel, use a mature engine (Synthesis) * add features in small steps (more manageable, immediately useful) -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
|
From: Daniel G. <go...@b1...> - 2011-01-04 10:36:57
|
On Tuesday, January 04, 2011 10:04:39 am Patrick Ohly wrote: > > In summary, I would like to understand why you feel that redirecting our > > efforts to SyncEvolution has any greater chance of success in solving the > > hard problems of syncing. > > My own summary, more at a meta level than the details above: > * don't reinvent the wheel, use a mature engine (Synthesis) What was your reason choosing SyncEvolution and not OpenSync to adapt to libsynthesis? We wouldn't have any "fragmentation" if you would have chosen OpenSync, and not SyncEvoluation, to adapt it to libsynthesis. Something I'm very interested and also prepared several changes for, and added additional complexity, to introduce libsynthesis in OpenSync. E.g. by making OpenSync independent of xmlformat. I'm still open to adapt OpenSync and it's plugin to make more use of common code - e.g. vcard handling of libsynthesis, maybe even seperating libsynthesis in sometihng like libvxx to provide a common code base for vformats not only for syncing application. I would be also happy if one day someone prepares patches which replace OSyncEngine with something based on libsynthesis. libsynthesis is definitely more mature code regarding vformat handling and the engine with regards of syncml. Not quite sure with regards generic synchronization. And i guess OpenSync Plugin API is more mature then SyncEvolution Backend API. But would be interesting to hear if there is any flaw inside OpenSync, why it wasn't chosen to adapt to libsynthesis. -- Daniel Gollub Linux Consultant & Developer Mail: go...@b1... B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 |
|
From: Patrick O. <pat...@gm...> - 2011-01-04 11:43:06
|
On Di, 2011-01-04 at 11:36 +0100, Daniel Gollub wrote:
> On Tuesday, January 04, 2011 10:04:39 am Patrick Ohly wrote:
> > > In summary, I would like to understand why you feel that redirecting our
> > > efforts to SyncEvolution has any greater chance of success in solving the
> > > hard problems of syncing.
> >
> > My own summary, more at a meta level than the details above:
> > * don't reinvent the wheel, use a mature engine (Synthesis)
>
>
> What was your reason choosing SyncEvolution and not OpenSync to adapt to
> libsynthesis?
Several reasons:
* libsynthesis did not (and still doesn't) fit into the OpenSync
architecture because engine and data conversion are closely
related. Arguably this is necessary, because one needs
information from the other (capabilities, choosing data
formats). Refactoring libsynthesis so that it fits into the
OpenSync plugin concept of formatters, backends and engine would
have been a major effort, both on libsynthesis and also
OpenSync. As you know, we discussed it at the time, but despite
all the emails that we exchanged I still did not fully
understand the OpenSync design and thus did not pursue this
further.
* State of OpenSync. We needed a fully working solution within a
few months for Moblin 1.0 beginning of 2009. Two years later
there still isn't a stable OpenSync release, so I think the
decision was justified. I also don't think that investing work
into OpenSync would have led to a different result (pure
speculation, of course - we'll never know).
> Something I'm very interested and also prepared several changes for, and added
> additional complexity, to introduce libsynthesis in OpenSync. E.g. by making
> OpenSync independent of xmlformat.
Unfortunately refactoring libsynthesis is still blocking that, and there
is no-one working on it. It simply isn't important enough because
libsynthesis works well for its current usage.
--
Bye, Patrick Ohly
--
Pat...@gm...
http://www.estamos.de/
|
|
From: Daniel G. <go...@b1...> - 2011-01-04 13:12:00
|
On Tuesday, January 04, 2011 12:42:55 pm Patrick Ohly wrote: > Several reasons: > * libsynthesis did not (and still doesn't) fit into the OpenSync > architecture because engine and data conversion are closely > related. Arguably this is necessary, because one needs > information from the other (capabilities, choosing data > formats). Refactoring libsynthesis so that it fits into the > OpenSync plugin concept of formatters, backends and engine would > have been a major effort, both on libsynthesis and also > OpenSync. Right. OpenSync is currently still working towards that until OpenSync or your or someone else solution full filled the goals OpenSync is targeting. > As you know, we discussed it at the time, but despite > all the emails that we exchanged I still did not fully > understand the OpenSync design and thus did not pursue this > further. I see. I'm sorry about that ... I invested a lot of time in supporting you as much information i was able to do in my limited time ... Synchronization is complex as you now. But this might also happen to SyncEvoluation that you will not get more contributors because nobody fully understand - beside you - how SyncEvoluation is designed. For OpenSync, i haven't done the initial design - and also managed to understand most of the implementation without contributing major implementation like Armin and many others did. So i just can give you the advice to make really really really good documentation. E.g. just having providing backend-samples is not enough. For OpenSync Documentation of the internals will be very likely the next thing I'm going to do, to enable other people to finish 0.40. > * State of OpenSync. We needed a fully working solution within a > few months for Moblin 1.0 beginning of 2009. Two years later > there still isn't a stable OpenSync release, so I think the > decision was justified. I also don't think that investing work > into OpenSync would have led to a different result (pure > speculation, of course - we'll never know). You need to contribute to projects if you want to gain something particular out of it. > > > Something I'm very interested and also prepared several changes for, and > > added additional complexity, to introduce libsynthesis in OpenSync. > > E.g. by making OpenSync independent of xmlformat. > > Unfortunately refactoring libsynthesis is still blocking that, and there > is no-one working on it. It simply isn't important enough because > libsynthesis works well for its current usage. I could imagine that it would be much more valuable for the FOSS community to re factor libsynthesis and OpenSync to have a lot common code base. While developing OpenSync for several years i got in touch with a lot of people developing PIM interfaces. And there is so much redundant code which could be common code base. libsynthesis is very mature and well maintained code and would be much more of use for the FOSS community if it would be refactored. Which might be not important for you, but for other projects. Currently i don't see syncevolutaion is replacing OpenSync today. Maybe it will some when in the future. Maybe not. It could disappear like other Sync approaches due to various reasons. I'm not going to declare OpenSync as dead. I highly recommend that OpenSync (Plugin) Developers decide by their own if syncevoluation is a better alternative for them or not. It would be pretty ignorant to say anything different. My personal goal is to support the FOSS community so they have some tool to have a rock-solid synchronization solution. I will not declare OpenSync as dead in favor of SyncEvoluation. Not only because I'm not in position to declare the project as dead. Because I'm not convinced that SyncEvoluation is an alternative to OpenSync to date. And also because i have the impression that there are still lot of people which still want contribute to OpenSync and those I want to support with my contribution. I doubt OpenSync is a "honey pot". Maybe your project is for various reason just not attractive enough. Maybe renaming it, like suggested by Chris would help. The only harmful thing for both project is - discussing that fragmentation is harmful ;) Instead each of us could concentrate on working towards their implementation make it just work. -- Daniel Gollub Linux Consultant & Developer Mail: go...@b1... B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 |
|
From: Patrick O. <pat...@gm...> - 2011-01-04 13:32:09
|
On Di, 2011-01-04 at 14:11 +0100, Daniel Gollub wrote: > Currently i don't see syncevolutaion is replacing OpenSync today. Maybe it > will some when in the future. Maybe not. It could disappear like other Sync > approaches due to various reasons. I'm not going to declare OpenSync as dead. > I highly recommend that OpenSync (Plugin) Developers decide by their own if > syncevoluation is a better alternative for them or not. It would be pretty > ignorant to say anything different. Fair enough. I've made my point, what kind of conclusions anyone draws from it is that person's own choice. I'll answer the open questions about SyncEvolution on the SyncEvolution mailing list and stop copying the OpenSync list. -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
|
From: Emanoil K. <del...@ya...> - 2011-01-08 20:30:51
|
Hello, Appart the plans for the future I think there is small effort needed to make the last step to a successfull sync with a phone over syncml and the current svn version of libopensync (0.40). I still can not believe that no one is using this framework for syncing with real phones. As I understood from Quentin he is busy ATM, so I want to sum up the current blocking issues and goals that we both think have a short term priority. I. Suggestions on high priority issues in the present First of all somebody has to put some effort into libsyncml and help Michael - if possible becoming his substitute and take over. I guess there is just a little bit needed to have positive results, but this goes beyond my goals and capabilities ATM and the desire Michael has to leave. Alternativ make plans to start libsynthesis plugin (it will take longer, but could be more beneficient). In both cases you need a dedicated person with long time plans to work in the area (syncml) Second, reorganise responsibilities for the future release and be ready to answer/fix user problems. With the current speed it does not make any sense to discuss whatever we are discussing here. Also document your own code and work on documenting the engine. I'm amased how good the akonadi documentation is. Third, do whatever needed to get a release in short terms. From my tests I think a compromise could be done easier i.e. if users are recommended to use different configurations for different obj-types, so that the slow sync issue could have less impact. I personally would accept such a deal, given the promise to fix it in future. The rest was discussed before. This issue is very nasty and I don't know what's necessary to have it fixed, but it needs to be done for a stable release - with no doubt. Fortunately it does not happen every time - so may be a workaround could be enough. II. Issues open and blocking my investigations/tests with kde (opensync/akonadi) and nokia 5530 (opensync/syncml) 1. libsyncml 1.a https://libsyncml.opensync.org/ticket/272#comment:1 this is libsyncml (as I mentioned before libwbxml seems to be working - tested with contact and calendar data) 1.b https://libsyncml.opensync.org/ticket/273 https://libsyncml.opensync.org/ticket/274 unknown alert type 255 breaks normal sync so the only option is slow-sync 1.c syncml-client/server could be better for current phones (but I'm not sure if this conclusion is true) also the code seems not to be clean and funcitonal at 100% 2. libopensync http://www.opensync.org/ticket/1442 http://www.opensync.org/ticket/1444 - a problem in the parser (converter) breaks sync of contact data Could we discuss in short terms how to solve these issues please! I'm willing to have a succcessfull sync with my phone soon and I'm sure if it works for me it will work for every one with a symbian nokia phone. Kind regards in advance |
|
From: Quentin D. <que...@gm...> - 2011-01-09 13:19:44
|
Thank you Emanoil for this good summary. I am in fact very busy right now, but I want to let you know that I approve the mentioned points. In the hope that this will have a positive outcome, kind regards! On Saturday 08 January 2011 21:30:44 Emanoil Kotsev wrote: > Hello, > > Appart the plans for the future I think there is small effort needed to > make the last step to a successfull sync with a phone over syncml and the > current svn version of libopensync (0.40). > > I still can not believe that no one is using this framework for syncing > with real phones. > > As I understood from Quentin he is busy ATM, so I want to sum up the > current blocking issues and goals that we both think have a short term > priority. > > I. Suggestions on high priority issues in the present > > First of all somebody has to put some effort into libsyncml and help > Michael - if possible becoming his substitute and take over. I guess there > is just a little bit needed to have positive results, but this goes beyond > my goals and capabilities ATM and the desire Michael has to leave. > > Alternativ make plans to start libsynthesis plugin (it will take longer, > but could be more beneficient). > > In both cases you need a dedicated person with long time plans to work in > the area (syncml) > > Second, reorganise responsibilities for the future release and be ready to > answer/fix user problems. With the current speed it does not make any > sense to discuss whatever we are discussing here. Also document your own > code and work on documenting the engine. I'm amased how good the akonadi > documentation is. > > Third, do whatever needed to get a release in short terms. From my tests I > think a compromise could be done easier i.e. if users are recommended to > use different configurations for different obj-types, so that the slow > sync issue could have less impact. I personally would accept such a deal, > given the promise to fix it in future. The rest was discussed before. > > This issue is very nasty and I don't know what's necessary to have it > fixed, but it needs to be done for a stable release - with no doubt. > Fortunately it does not happen every time - so may be a workaround could > be enough. > > > II. Issues open and blocking my investigations/tests with kde > (opensync/akonadi) and nokia 5530 (opensync/syncml) > > 1. libsyncml > > 1.a https://libsyncml.opensync.org/ticket/272#comment:1 > this is libsyncml (as I mentioned before libwbxml seems to be working - > tested with contact and calendar data) > > 1.b https://libsyncml.opensync.org/ticket/273 > https://libsyncml.opensync.org/ticket/274 > > unknown alert type 255 breaks normal sync so the only option is slow-sync > > 1.c syncml-client/server could be better for current phones (but I'm not > sure if this conclusion is true) also the code seems not to be clean and > funcitonal at 100% > > > 2. libopensync > > http://www.opensync.org/ticket/1442 > http://www.opensync.org/ticket/1444 - a problem in the parser (converter) > breaks sync of contact data > > Could we discuss in short terms how to solve these issues please! > > I'm willing to have a succcessfull sync with my phone soon and I'm sure if > it works for me it will work for every one with a symbian nokia phone. > > Kind regards in advance |
|
From: Chris F. <cd...@fo...> - 2011-01-14 20:27:35
|
On Sat, Jan 08, 2011 at 12:30:44PM -0800, Emanoil Kotsev wrote: > 2. libopensync > > http://www.opensync.org/ticket/1442 > http://www.opensync.org/ticket/1444 - a problem in the parser (converter) breaks sync of contact data Can you grab the latest vformat plugin from SVN and give it a try? If it works, can you close the above tickets for me? :-) Thanks, - Chris |
|
From: Emanoil K. <del...@ya...> - 2011-01-18 22:49:28
|
it seems I can not reproduce this any more --- On Fri, 1/14/11, Chris Frey <cd...@fo...> wrote: > > > > http://www.opensync.org/ticket/1442 > > http://www.opensync.org/ticket/1444 - a > problem in the parser (converter) breaks sync of contact > data > > > Can you grab the latest vformat plugin from SVN and give it > a try? > > If it works, can you close the above tickets for me? :-) > however I have this error, which sounds like http://www.opensync.org/ticket/1182 and http://www.opensync.org/ticket/1173 and http://www.opensync.org/ticket/1147 element Location: Schemas validity error : Element 'Location': Missing child element(s). Expected is ( Longitude ). ERROR: XMLFormat validation failed. EXIT_ERROR: osync_converter_invoke: XMLFormat validation failed. EXIT_ERROR: osync_format_env_convert: XMLFormat validation failed. Main sink of member 1 of type syncml-obex-client had an error: XMLFormat validation failed. EXIT_ERROR: _osync_engine_receive_change: XMLFormat validation failed. in the thread log [1295389667.347122] >>>>>>> _osync_client_proxy_message_handler(0x7f7e9c13c940, 0x237aea0) [1295389667.347135] proxy received command 10 [1295389667.347150] Data is: 0x7f7e940ec6d0, 2327 [1295389667.347172] >>>>>>> _osync_engine_receive_change(0x237aea0, 0x21b7020, 0x7f7e940e9270) [1295389667.347185] Received change 540, changetype 1, format vcard21, objtype contact from member 1 [1295389667.347199] >>>>>>> osync_format_env_detect_objformat_full(0x21b9980, 0x7f7e940eb180, 0x7f7ea5f3ec28, 0x7f7ea5f3ec30) [1295389667.347213] We cannot copy the change, falling back to memcpy [1295389667.347228] <<<<<<< osync_format_env_detect_objformat_full: (nil) [1295389667.347242] common format 0x21ba000 for objtype contact [1295389667.347255] converting to format xmlformat-contact [1295389667.347268] >>>>>>> osync_format_env_convert(0x21b9980, 0x223c0b0, 0x7f7e940eb180, 0x7f7ea5f3ec30) [1295389667.347282] >>>>>>> osync_converter_invoke(0x21bcd50, 0x7f7e940eb180, , 0x7f7ea5f3ec30) [1295389667.347296] Converter of type 1, from 0x21bb410(vcard21) to 0x21ba000(xmlformat-contact) [1295389667.347309] >>>>>>> Converter function from "vcard21" to "xmlformat-contact" - input_data: 0x7f7e940ec6d0 input_size: 2327 [1295389667.347331] >>>>>>> conv_vcard_to_xmlformat(BEGIN:VCARD VERSION:2.1 REV:20100725T123728Z N:XXXX;Markus;;; FN:Markus XXXX ADR;HOME;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:= 7/2/8;;XXXXXXXXXXXXX=0D=0ANr.=207=0D=0AStiege=202=0D=0AT=C3=BCr=208;Wien;;= 1070;=C3=96sterreich ORG:;4 Semester BDAY:19840423 EMAIL;INTERNET;ENCODING=QUOTED-PRINTABLE:ich=40markus-raab.org GEO:48.150002\;17.116667 KEY;PGP;ENCODING=BASE64: mQGiBEUgu50RBAC9i47QyffjcdSrtDya1kzDeMULtmuzA2N7KqOgeLm70tvpEYkl KAzEi0Whhf4C5uKeEnusdDiE71cBL9X5eiv5boWbk4XeoOJT+IehZmFLeTkFvg3w Uf9pvmTNGJJGLa80KTpKE8KpbmKhfgXmsyzAE+nXEg3p8Qss9MHDvPrXnwCgpaMy 0LBpXGqA3C5KtwWkMJTFcx0EAI3/e17yStTlZ3QBYC7XlEvlPQznhNSncdcLlquI 2Cx+gDSoyIAFJQXa4DC8eGrKxaWdZcyN/YF1C1gAqoOouqht3xG8Miv69tzRjcco hGeLpB7YxMX+EFHGRz0AVZsZTIB4/tK30y5oQYpuJk1j3H7JgvOsQGSTTd6QmA7X lwb8BACu9L2Vu4ph9nIH3xGLVYn+XsVtaWYfgEVbd+ku96hhJ3yPltPPl7dORlOP I8H7+C+/a46Tf8oyIn4940zN8gpCWpEQIU2z5twTpawy2wYikQRatWooj/G+ypo3 RJzjqIbk8Jrk/jseP8mFU0ijX3B3RTjZOIzVVuSFXwjzs3EAkbQ6TWFya3VzIFJh YWIgKEZvciBUdXgsIEtvbnFpIGFuZCBHUEwpIDxpY2hAbWFya3VzLXJhYWIub3Jn PohmBBMRAgAmBQJFILudAhsDBQkJZgGABgsJCAcDAgQVAggDBBYCAwECHgECF4AA CgkQYzoCH2RXaMpQkgCePOEBY6xHVogUVrDapqkwVnMwJTMAn2nwoNBC9DAWodnJ clSMnlCG0MguuQINBEUgu6IQCADBCN6DxyM14aDayo2kvNSc6T0JhjtxqPhlOACc 5RTGR5kqbMaaLqhZQcwThtHbMJhQ3JLjk50TqNPXOIRWexdoC+gPUHJwjBDKdKfX NcOn8u/OqIldRpiFnOIjDxcJQkRhOrHhP12uMbDzhqwVXoy+HX7lFQrI67jvUPkf HlQ9IKo5flbIjD9YmfU89m50avzsIIz9wrFYyBVQvR/f56UCQG3ji14pBFy/vt5W xm0hNNO0laufPV/CdN3KBGGaKkzVntEsmqW5WKw7P/qDvyTWsfr8y7obCjA+K93Q 9SbS61tkqwH6sd4CvGn5Uu+sGj2gYTrBQqo0d5v6reyezBwrAAMFB/4rUg+YEKuo ViYkvmwiHwGBiBlysjw7QHhxspXbudrFm24R8wyUCyfaUHL/8aV8Om6F6D7H+Xha hFNSKIGxLFHiag8KJmiGccEWdPLpHhia4Hfa2/GT8iXmcGNqKoy02tQvgr7ux2AF a0qe5qcUQJCfH+ff6dQR3HhUjzutts612uKlRED9zXBcowyazUVzeWS3Vy29ORKR N9rMBvLP0lZ71jeZjwBNauq1LCYZqItDzukSK68UF6XfWE5UdL1JCkwzEaxhEWr4 AC0Sjq+czGxrs/cq44uIDihPa3FV6c2SKy+++myWMOwHeq/dZ4ZhuJGQsW0O0a4N 4N5hj7tEzClHiE8EGBECAA8FAkUgu6ICGwwFCQlmAYAACgkQYzoCH2RXaMrD7ACg kCPD/1W2zfrqT6Q5Jx9MTwIf8l4An35AWFOVvKKgMUcCEjKGqvnne/Mg NOTE;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:= Besuchen=20sie=20die=20Homepage=20f=C3=BCr=20die=20aktuellen=20Daten=21= =0D=0AIch=20freue=20mich=20=C3=BCber=20Anrufe:=208:00-24:00 TEL;CELL:0650 NNNNNNNN URL:http://www.markus-XXXXXXX.org END:VCARD , 2327, 0x7f7ea5f3eb10, 0x7f7ea5f3eb28, 0x7f7ea5f3eb24, , (nil), 0x7f7ea5f3ec30) [1295389667.347352] >>>>>>> init_vcard_to_xmlformat [1295389667.347369] <<<<<<< init_vcard_to_xmlformat: 0x7f7e940e7490 [1295389667.347387] [SENSITIVE CONTENT HIDDEN] [1295389667.347534] [_read_attribute_value] escape carriage returns!! [1295389667.347563] Creating xmlformat object [1295389667.347577] >>>>>>> osync_xmlformat_new(0x7f7eb767b250, 0x7f7ea5f3ec30) [1295389667.347591] <<<<<<< osync_xmlformat_new: 0x7f7e940eee20 [1295389667.347604] parsing attributes [1295389667.347656] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940ebbc0:VERSION, 0x7f7ea5f3ec30) [1295389667.347681] Hook is: 0x1 [1295389667.347694] <<<<<<< handle_attribute: Ignored [1295389667.347708] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940eb510:REV, 0x7f7ea5f3ec30) [1295389667.347722] Hook is: 0x7f7eb766a610 [1295389667.347734] Handling Revision attribute [1295389667.347747] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Revision, 0x7f7ea5f3ec30) [1295389667.347761] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.347774] <<<<<<< osync_xmlformat_set_unsorted [1295389667.347787] <<<<<<< osync_xmlfield_new: 0x7f7e940edd80 [1295389667.347801] >>>>>>> osync_time_timestamp(20100725T123728Z) [1295389667.347815] <<<<<<< osync_time_timestamp: 20100725T123728Z [1295389667.347829] Number of parameters: 0 [1295389667.347841] <<<<<<< handle_attribute [1295389667.347897] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e95f0:N, 0x7f7ea5f3ec30) [1295389667.347913] Hook is: 0x7f7eb7669740 [1295389667.347926] Handling name attribute [1295389667.347939] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Name, 0x7f7ea5f3ec30) [1295389667.347953] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.347965] <<<<<<< osync_xmlformat_set_unsorted [1295389667.347978] <<<<<<< osync_xmlfield_new: 0x7f7e940ee3a0 [1295389667.347996] Number of parameters: 0 [1295389667.348008] <<<<<<< handle_attribute [1295389667.348021] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e62f0:FN, 0x7f7ea5f3ec30) [1295389667.348035] Hook is: 0x7f7eb7669850 [1295389667.348047] Handling formatted name attribute [1295389667.348060] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, FormattedName, 0x7f7ea5f3ec30) [1295389667.348074] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348086] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348098] <<<<<<< osync_xmlfield_new: 0x7f7e940ee130 [1295389667.348112] Number of parameters: 0 [1295389667.348124] <<<<<<< handle_attribute [1295389667.348137] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e3750:ADR, 0x7f7ea5f3ec30) [1295389667.348150] Hook is: 0x7f7eb7669540 [1295389667.348162] Handling address attribute [1295389667.348175] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Address, 0x7f7ea5f3ec30) [1295389667.348188] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348201] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348213] <<<<<<< osync_xmlfield_new: 0x7f7e940ef060 [1295389667.348231] Number of parameters: 2 [1295389667.348244] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940ef060, 0x7f7e940dd860) [1295389667.348258] Handling Location parameter TYPE [1295389667.348271] <<<<<<< handle_parameter [1295389667.348284] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940ef060, 0x7f7e940e6920) [1295389667.348298] <<<<<<< handle_parameter [1295389667.348310] <<<<<<< handle_attribute [1295389667.348323] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e9040:ORG, 0x7f7ea5f3ec30) [1295389667.348336] Hook is: 0x7f7eb766a6d0 [1295389667.348349] Handling Organization attribute [1295389667.348361] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Organization, 0x7f7ea5f3ec30) [1295389667.348375] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348388] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348400] <<<<<<< osync_xmlfield_new: 0x7f7e940efe70 [1295389667.348415] Number of parameters: 0 [1295389667.348427] <<<<<<< handle_attribute [1295389667.348451] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e8fa0:BDAY, 0x7f7ea5f3ec30) [1295389667.348465] Hook is: 0x7f7eb766a7d0 [1295389667.348477] Handling birthday attribute [1295389667.348490] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Birthday, 0x7f7ea5f3ec30) [1295389667.348503] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348516] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348528] <<<<<<< osync_xmlfield_new: 0x7f7e940efeb0 [1295389667.348542] >>>>>>> osync_time_datestamp(19840423) [1295389667.348555] <<<<<<< osync_time_datestamp: 19840423 [1295389667.348568] Number of parameters: 0 [1295389667.348581] <<<<<<< handle_attribute [1295389667.348594] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940e8a70:EMAIL, 0x7f7ea5f3ec30) [1295389667.348608] Hook is: 0x7f7eb7669280 [1295389667.348625] Handling EMail attribute [1295389667.348638] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, EMail, 0x7f7ea5f3ec30) [1295389667.348652] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348664] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348677] <<<<<<< osync_xmlfield_new: 0x7f7e940f0350 [1295389667.348691] Number of parameters: 1 [1295389667.348703] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940f0350, 0x7f7e940e8fe0) [1295389667.348716] Handling Internet EMailType parameter TYPE [1295389667.348729] <<<<<<< handle_parameter [1295389667.348742] <<<<<<< handle_attribute [1295389667.348755] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940ed370:GEO, 0x7f7ea5f3ec30) [1295389667.348768] Hook is: 0x7f7eb7669050 [1295389667.348780] Handling Location attribute [1295389667.348793] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Location, 0x7f7ea5f3ec30) [1295389667.348807] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348819] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348832] <<<<<<< osync_xmlfield_new: 0x7f7e940f05e0 [1295389667.348846] Number of parameters: 0 [1295389667.348858] <<<<<<< handle_attribute [1295389667.348871] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940ed3f0:KEY, 0x7f7ea5f3ec30) [1295389667.348884] Hook is: 0x7f7eb7668c30 [1295389667.348896] Handling Key attribute [1295389667.348909] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Key, 0x7f7ea5f3ec30) [1295389667.348962] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.348975] <<<<<<< osync_xmlformat_set_unsorted [1295389667.348988] <<<<<<< osync_xmlfield_new: 0x7f7e940f07c0 [1295389667.349004] Number of parameters: 1 [1295389667.349020] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940f07c0, 0x7f7e940ed450) [1295389667.349034] <<<<<<< handle_parameter [1295389667.349046] <<<<<<< handle_attribute [1295389667.349059] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940ec4e0:NOTE, 0x7f7ea5f3ec30) [1295389667.349072] Hook is: 0x7f7eb7668d90 [1295389667.349084] Handling Note attribute [1295389667.349095] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Note, 0x7f7ea5f3ec30) [1295389667.349108] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.349120] <<<<<<< osync_xmlformat_set_unsorted [1295389667.349132] <<<<<<< osync_xmlfield_new: 0x7f7e940f1ad0 [1295389667.349145] Number of parameters: 1 [1295389667.349158] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940f1ad0, 0x7f7e940edbd0) [1295389667.349170] <<<<<<< handle_parameter [1295389667.349182] <<<<<<< handle_attribute [1295389667.349195] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940eec30:TEL, 0x7f7ea5f3ec30) [1295389667.349216] Hook is: 0x7f7eb7669330 [1295389667.349228] Handling Telephone attribute [1295389667.349240] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Telephone, 0x7f7ea5f3ec30) [1295389667.349252] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.349264] <<<<<<< osync_xmlformat_set_unsorted [1295389667.349276] <<<<<<< osync_xmlfield_new: 0x7f7e940f1da0 [1295389667.349289] Number of parameters: 1 [1295389667.349302] >>>>>>> handle_parameter(0x7f7e9c007230, 0x7f7e940f1da0, 0x7f7e940e8be0) [1295389667.349315] Handling Type parameter TYPE [1295389667.349327] <<<<<<< handle_parameter [1295389667.349339] <<<<<<< handle_attribute [1295389667.349352] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940eed20:URL, 0x7f7ea5f3ec30) [1295389667.349364] Hook is: 0x7f7eb76647d0 [1295389667.349376] Handling Url attribute [1295389667.349388] >>>>>>> osync_xmlfield_new(0x7f7e940eee20, Url, 0x7f7ea5f3ec30) [1295389667.349401] >>>>>>> osync_xmlformat_set_unsorted(0x7f7e940eee20) [1295389667.349413] <<<<<<< osync_xmlformat_set_unsorted [1295389667.349425] <<<<<<< osync_xmlfield_new: 0x7f7e940f2470 [1295389667.349438] Number of parameters: 0 [1295389667.349450] <<<<<<< handle_attribute [1295389667.349462] >>>>>>> handle_attribute(0x7f7e9c0071e0, 0x7f7e9c007230, 0x7f7e940eee20, 0x7f7e940eed90:END, 0x7f7ea5f3ec30) [1295389667.349477] Hook is: 0x1 [1295389667.349489] <<<<<<< handle_attribute: Ignored [1295389667.349503] >>>>>>> osync_xmlformat_sort(0x7f7e940eee20) [1295389667.349518] <<<<<<< osync_xmlformat_sort [1295389667.349565] [SENSITIVE CONTENT HIDDEN] [1295389667.349588] <<<<<<< conv_vcard_to_xmlformat: TRUE [1295389667.349603] <<<<<<< Converter function. output_size: 56, output_data: 0x7f7e940eee20 [1295389667.349631] >>>>>>> validate_xmlformat(0x7f7e940eee20, 56, 0x21bd150, 0x7f7ea5f3ec30) [1295389667.349710] ERROR: XMLFormat validation failed. [1295389667.349729] <<<<<<< validate_xmlformat: FALSE [1295389667.349742] <--- ERROR --- osync_converter_invoke: XMLFormat validation failed. [1295389667.349760] <--- ERROR --- osync_format_env_convert: XMLFormat validation failed. [1295389667.349776] >>>>>>> osync_status_update_member(0x21b7020, 0x202ab60, 3, (null), 0x7f7e940e7490) [1295389667.349790] >>>>>>> member_status(0x7f7e940efb60, (nil)) [1295389667.349808] <<<<<<< member_status [1295389667.349822] <<<<<<< osync_status_update_member [1295389667.349834] <--- ERROR --- _osync_engine_receive_change: XMLFormat validation failed. [1295389667.349850] <<<<<<< _osync_client_proxy_message_handler [1295389667.349864] Dispatching 0x7f7e9c13dec0:10(OSYNC_MESSAGE_NEW_CHANGE), timeout=0, id=0 [1295389667.349877] >>>>>>> _osync_client_proxy_message_handler(0x7f7e9c13dec0, 0x237aea0) [1295389667.349889] proxy received command 10 [1295389667.349904] Data is: 0x7f7e940e8a70, 112 |
|
From: Chris F. <cd...@fo...> - 2011-01-19 02:12:38
|
On Tue, Jan 18, 2011 at 02:49:20PM -0800, Emanoil Kotsev wrote: > VERSION:2.1 > REV:20100725T123728Z > N:XXXX;Markus;;; > FN:Markus XXXX > ADR;HOME;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:= > 7/2/8;;XXXXXXXXXXXXX=0D=0ANr.=207=0D=0AStiege=202=0D=0AT=C3=BCr=208;Wien;;= > 1070;=C3=96sterreich > ORG:;4 Semester > BDAY:19840423 > EMAIL;INTERNET;ENCODING=QUOTED-PRINTABLE:ich=40markus-raab.org > GEO:48.150002\;17.116667 There appears to be a problem with this line. If you remove the escape backslash, then it should work. Otherwise, the full string is taken as the Latitude (48.150002;17.116667) and there is no Longitude, and the XMLFormat validation rightly complains. - Chris |
|
From: Emanoil K. <del...@ya...> - 2011-01-19 10:51:56
|
--- On Wed, 1/19/11, Chris Frey <cd...@fo...> wrote: > From: Chris Frey <cd...@fo...> > Subject: Re: [Opensync-devel] OpenSync priorities > To: ope...@li... > Date: Wednesday, January 19, 2011, 3:12 AM > On Tue, Jan 18, 2011 at 02:49:20PM > -0800, Emanoil Kotsev wrote: > > VERSION:2.1 > > REV:20100725T123728Z > > N:XXXX;Markus;;; > > FN:Markus XXXX > > ADR;HOME;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:= > > > 7/2/8;;XXXXXXXXXXXXX=0D=0ANr.=207=0D=0AStiege=202=0D=0AT=C3=BCr=208;Wien;;= > > 1070;=C3=96sterreich > > ORG:;4 Semester > > BDAY:19840423 > > > EMAIL;INTERNET;ENCODING=QUOTED-PRINTABLE:ich=40markus-raab.org > > GEO:48.150002\;17.116667 > > There appears to be a problem with this line. If you > remove the > escape backslash, then it should work. > > Otherwise, the full string is taken as the Latitude > (48.150002;17.116667) > and there is no Longitude, and the XMLFormat validation > rightly > complains. > Thanks. I'll try to do this next. regards |
|
From: Emanoil K. <del...@ya...> - 2011-01-19 21:33:22
|
hi, thanks, this was the blocking issue
unfortunately I couldn't edit this field on the phone. it was not visible there, so I've just deleted the entry and I was able to sync my contatcs to akonadi.
May be some of the other "cool" sync applications did this to the GEO field. no idea
my next goal would be to handle this with kdepim.
I can not read the calendar from the phone :-( but this is another topic. I'll post my findings in the akonadi thread.
regards
|
|
From: Graham C. <g+o...@co...> - 2011-01-20 14:50:09
|
On Wednesday 19 January 2011 02:12:31 Chris Frey wrote: > On Tue, Jan 18, 2011 at 02:49:20PM -0800, Emanoil Kotsev wrote: > > GEO:48.150002\;17.116667 > > There appears to be a problem with this line. If you remove the > escape backslash, then it should work. > > Otherwise, the full string is taken as the Latitude (48.150002;17.116667) > and there is no Longitude, and the XMLFormat validation rightly > complains. Experience teaches us that implementation of the V-formats in the real world is very poor! It would be worth both the vformat and xmlformat code in OpenSync to be more tolerant. OpenSync is in the business of syncing user's devices, not enforcing minor standards violations. As this particular bad encoding has now been seen in the real world we can assume it will be seen again. It seems like the vformat code could, and should, handle it, as a variant and parse the GEO: with the \; as well as the correct version without the \. However, in any case, it should also make sure it **always** generates valid XML (or none at all). So, GEO:xxx should generate either no <Location> or a valid one. There may also be a case that the xmlformat code should just be dropping badly formatted fields although, as a purely internal format, I can see the justification for aborting, but only if the code which creates the XML is capable enough to always generate either no field or a correctly formatted field. Graham |
|
From: Juergen L. <jue...@gm...> - 2011-01-20 19:31:23
|
On Thu, Jan 20, 2011 at 02:49:55PM +0000, Graham Cobb wrote: > On Wednesday 19 January 2011 02:12:31 Chris Frey wrote: > > On Tue, Jan 18, 2011 at 02:49:20PM -0800, Emanoil Kotsev wrote: (...) > Experience teaches us that implementation of the V-formats in the real world > is very poor! It would be worth both the vformat and xmlformat code in > OpenSync to be more tolerant. OpenSync is in the business of syncing user's > devices, not enforcing minor standards violations. Yes, you are absolutely right. OpenSync should be way more tolerant towards format errors. A format error is not the same as an exit error in terms of libopensync, which automatically leads to slow-sync of all of the entries available. (...) > There may also be a case that the xmlformat code should just be dropping badly > formatted fields although, as a purely internal format, I can see the > justification for aborting, but only if the code which creates the XML is > capable enough to always generate either no field or a correctly formatted > field. (...) Exactly. A WARNING would do it, as well. Bye, bye Juergen. |
|
From: Chris F. <cd...@fo...> - 2011-01-20 19:42:52
|
On Thu, Jan 20, 2011 at 08:31:07PM +0100, Juergen Leising wrote: > On Thu, Jan 20, 2011 at 02:49:55PM +0000, Graham Cobb wrote: > > On Wednesday 19 January 2011 02:12:31 Chris Frey wrote: > > > On Tue, Jan 18, 2011 at 02:49:20PM -0800, Emanoil Kotsev wrote: > (...) > > > Experience teaches us that implementation of the V-formats in the real world > > is very poor! It would be worth both the vformat and xmlformat code in > > OpenSync to be more tolerant. OpenSync is in the business of syncing user's > > devices, not enforcing minor standards violations. > > Yes, you are absolutely right. OpenSync should be way more > tolerant towards format errors. A format error is not the same > as an exit error in terms of libopensync, which automatically > leads to slow-sync of all of the entries available. I don't know which software stack is creating this vCard data. Emanoil: can you let us know if you are getting this data from Akonadi or if you are creating it yourself? If the plugin is creating the vCard data, the plugin should be fixed, not the parser. But, if people have time on their hands, and want to hack on the code, go to the vformat plugin, in src/xmlformat-vcard.c, line 444, and change the handle_location_attribute() function. Test code would also be nice. :-) - Chris |
|
From: Emanoil K. <del...@ya...> - 2011-01-21 10:08:20
|
Hi, thanks for the discussion and paying attention to this subject.
--- On Thu, 1/20/11, Chris Frey <cd...@fo...> wrote:
> > > Experience teaches us that implementation of the
> V-formats in the real world
> > > is very poor! It would be worth both the
> vformat and xmlformat code in
> > > OpenSync to be more tolerant. OpenSync is
> in the business of syncing user's
> > > devices, not enforcing minor standards
> violations.
> >
> > Yes, you are absolutely right. OpenSync should
> be way more
> > tolerant towards format errors. A format error
> is not the same
> > as an exit error in terms of libopensync, which
> automatically
> > leads to slow-sync of all of the entries available.
>
> I don't know which software stack is creating this vCard
> data.
>
> Emanoil: can you let us know if you are getting this data
> from Akonadi
> or if you are creating it
> yourself? If the plugin is creating
> the vCard data, the plugin should be
> fixed, not the parser.
The history as follows. After I bought the phone I used windows to sync my contacts from the old phones (nokia and sony-err). I've managed then to sync my contacts with kde3 (somehow, with having a lot of duplicates) with opensync 0.22. After this I've been using Nokia in windows (vmware) and later the SyncEvolution app. So I guess somehow this contact was transfered to the phone. Now the strange thing is that this GEO field is not visible on the phone and I can not edit it.
>
> But, if people have time on their hands, and want to hack
> on the code,
> go to the vformat plugin, in src/xmlformat-vcard.c, line
> 444, and
> change the handle_location_attribute() function. Test
> code would also
> be nice. :-)
>
I'll have a look at it.
regards
|
|
From: Emanoil K. <del...@ya...> - 2011-01-27 21:59:14
|
Quentin mentioned you have discussed the sync of UIDs. Can we discuss this too. Currently I am able to read contacts from the phone and I have a problem with the way the uid is handled around the changes and by the plugins. Also in the understanding of the qint type in kde4 ... I need to read more about this how the uid is generated. AFAIK akonadi generates internal id and supports a remoteId field to be correlated to external. Anyway I need some better understanding here how opensync handles it.
Imagine I have created a contact with UID=XYZ in kde and another one with UID=XYZ on the phone.
A second case kde UID=XYZ and the same contact with uid=ABC on the phone.
I see that kdepim plugin checks if such contact exists and !deletes! it. In my opinion it is not a satisfactory solution unless the content is the same, but is it? My fear is that it deletes a contact different in content but with same id or that I end up with duplicates
thanks in advance
regards
|
Thanks for helping keep SourceForge clean.
X