From: Mark E. <ma...@mp...> - 2013-10-11 09:56:26
|
On Fri, 2013-10-11 at 03:14 +0200, Chris Frey wrote: > On Thu, Sep 26, 2013 at 02:25:01PM +0100, Mark Ellis wrote: > > So eventually I disabled all the capability code in evo sync, and it > > "fixed" the problem. Evo sync currently builds capabilities for > > contacts, but not any other objtype, so apparently opensync reads this > > as the other objtypes having no capabilities at all. > > I don't understand this behaviour yet. This needs some investigation > I thinkg. > > I know exactly where you're coming from, this was a a most confusing experience. > > So, attached patch adds capabilities for calendar objtypes. This info > > can't be gained from evolution like contact capabilities can, so I've > > put it together the best I can through experimentation. I don't want it > > committed yet, but would appreciate someone else eyeballing it briefly > > before I get it tested by the guy that brought this to my attention > > using synce and evo. > > Sorry to mention this so late, after you've done the work, but I think > there is a file format for capabilities already, in XML. If we can't > auto-detect them in code, we should be able to just write a capabilities > file and have opensync load it. > > See the misc/capabilities/ directory in opensync. I believe the kdepim > plugin uses this as well. > You're absolutely right, and I thought that would be a great idea, but then I found out you cant mix the two types, ie static for the calendar objtypes and dynamic for contacts. When it didn't work I traced it through the code, it's in opensync_client_proxy.c, _osync_client_proxy_read_discover_message(). If we find some static caps, we use those, otherwise we use the caps from discover. So either we use static caps for all objtypes in evo sync, or we get the contact caps from evo and build the calendar caps inside the plugin. Mark |