From patrick.ohly at gmx.de Wed Jan 5 08:56:52 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Wed, 05 Jan 2011 09:56:52 +0100 Subject: Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: <158596.800.qm@web161202.mail.bf1.yahoo.com> References: <158596.800.qm@web161202.mail.bf1.yahoo.com> Message-ID: <1294217812.5803.1449.camel@pohly-mobl1.ikn.intel.com> [moving to SyncEvolution list] On Di, 2011-01-04 at 10:30 -0800, Emanoil Kotsev wrote: > 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 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. I should have mentioned that Dinesh is working on it; I just haven't seen the result yet and don't know whether he wants to stay around once it is included (maintenance!). > 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). Dinesh, is there a chance that Emanoil helps with the SyncEvolution Akonadi backend? I can imagine that the work can be split up easily (for example, you doing the KDE integration (HTTP, KWallet, GUI), while Emanoil does the actual sync backend), but you know best what the current status is. Emanoil, attached Dinesh's last email on the subject. None of his work is in the main SyncEvolution. We did one code review a while back and determined that further work was needed to make it ready. I'd be very interested to get as many suitable patches integrated now. 1.2 (= master) is still in an experimental phase, so modifying core code is okay. The Akonadi backend can be modified at any time, it is just a question of when it is ready for users. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -------------- next part -------------- A non-text attachment was scrubbed... Name: Re:_[SyncEvolution]_Kontact_s_ics-calendar-file_to_N900_synchronises_properly_until_VTODO_s_or_VJOURNAL_items_are_present. Type: application/mbox Size: 13402 bytes Desc: not available URL: From saidinesh5 at gmail.com Wed Jan 5 14:21:51 2011 From: saidinesh5 at gmail.com (Dinesh) Date: Wed, 5 Jan 2011 19:51:51 +0530 Subject: Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: <1294217812.5803.1449.camel@pohly-mobl1.ikn.intel.com> References: <158596.800.qm@web161202.mail.bf1.yahoo.com> <1294217812.5803.1449.camel@pohly-mobl1.ikn.intel.com> Message-ID: Hi, On 1/5/11, Patrick Ohly wrote: > [moving to SyncEvolution list] > > On Di, 2011-01-04 at 10:30 -0800, Emanoil Kotsev wrote: >> 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 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. > > I should have mentioned that Dinesh is working on it; I just haven't > seen the result yet and don't know whether he wants to stay around once > it is included (maintenance!). I would be glad to stay around, provided that there is something for me to work on :) > >> 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). > > Dinesh, is there a chance that Emanoil helps with the SyncEvolution > Akonadi backend? I can imagine that the work can be split up easily (for > example, you doing the KDE integration (HTTP, KWallet, GUI), while > Emanoil does the actual sync backend), but you know best what the > current status is. Would certainly like to have as much help as we can. Here is the detailed progress though: After the GSoC is over, the only problem left with the backend was the KDE specific extensions. The actual sync was working with both the HTTP transport and Obex .(As expected ,on second sync, the KDE specific fields are wiped out.). Syncevolution can now store credentials in KWallet backend. The compilation issues and segmentation faults are hopefully fixed. (We are still hard coding values in autotools though :( ) The Bluedevil plugin is also here. It currently does exactly what the Gnome Bluetooth Plugin does, but modifying it to do something else shouldn't take much time(Around 1 hour of work) The KDE's Notes doesn't yet use akonadi, so syncing notes is only tested with just a collection, using akonadiconsole. Whats really needed is a GUI and rigorous automated testing (I used to test it with my N70 and Ovi server after every change i made to my data and haven't yet had any problems though, but that doesn't mean there aren't any). > Emanoil, attached Dinesh's last email on the subject. None of his work > is in the main SyncEvolution. We did one code review a while back and > determined that further work was needed to make it ready. > I'd be very interested to get as many suitable patches integrated now. > 1.2 (= master) is still in an experimental phase, so modifying core code > is okay. The Akonadi backend can be modified at any time, it is just a > question of when it is ready for users. Sascha and I have cleaned up the code as suggested after that. Also have removed the libproxy that I have added temporarily, because of certain problems that libproxy has with KDE 4.4. I have tested both libsoup and libcurl: they seem to be working properly. Getting the backend ready is top on my list, then a proper GUI and may be after that, adding additional transport agent based on KIO. I was hoping to finish off the KDE specific extensions first, but currently am stuck with some weird problem with my KOrganizer. The personal deadline i gave myself, is with KDE PIM 4.6, we should be able to have a well tested SyncEvolution, atleast the CLI. I guess with some additional help, i m sure we can reach that. Emanoil, Please test the current backend from my repository as described in: http://saidinesh5.wordpress.com/2010/08/24/are-we-there-yet/ This should give you an overview of how to set things up: http://blogs.forum.nokia.com/blog/sivan-greenbergs-forum-nokia-blog/2010/11/07/kde-ovi-qt-meego-syncml Once after that, you will get to know whats left to do. Feel free to ping me on #akonadi-syncml (freenode) or via. Gmail. Regards, Dinesh > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > From patrick.ohly at gmx.de Thu Jan 6 07:27:28 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Thu, 06 Jan 2011 08:27:28 +0100 Subject: [SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: References: <158596.800.qm@web161202.mail.bf1.yahoo.com> <1294217812.5803.1449.camel@pohly-mobl1.ikn.intel.com> Message-ID: <1294298848.16093.220.camel@pohly-mobl1.ikn.intel.com> On Mi, 2011-01-05 at 14:21 +0000, Dinesh wrote: > On 1/5/11, Patrick Ohly wrote: > > I should have mentioned that Dinesh is working on it; I just haven't > > seen the result yet and don't know whether he wants to stay around once > > it is included (maintenance!). > > I would be glad to stay around, provided that there is something for > me to work on :) I'm sure users will give you plenty to work on, once they get their hands onto a release ;-) -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at yahoo.com Sat Jan 8 12:36:34 2011 From: deloptes at yahoo.com (Emanoil Kotsev) Date: Sat, 8 Jan 2011 04:36:34 -0800 (PST) Subject: [SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: <1294298848.16093.220.camel@pohly-mobl1.ikn.intel.com> Message-ID: <634811.44058.qm@web161202.mail.bf1.yahoo.com> Patrik, Dinesh, hello. Thank you for cc-ing me in your discussion. --- On Thu, 1/6/11, Patrick Ohly wrote: > From: Patrick Ohly > Subject: Re: [SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) > To: "Dinesh" > Cc: "Emanoil Kotsev" , "Sascha Peilicke" , "SyncEvolution" > Date: Thursday, January 6, 2011, 8:27 AM > On Mi, 2011-01-05 at 14:21 +0000, > Dinesh wrote: > > On 1/5/11, Patrick Ohly > wrote: > > > I should have mentioned that Dinesh is working on > it; I just haven't > > > seen the result yet and don't know whether he > wants to stay around once > > > it is included (maintenance!). I'm working as a consultant in telecommunications (provisioning) especially in testing and analysis but also offering solutions for small and medium businesses. I'm a hobby c++ developer and I have a degree in linguistics, AI and translation, so that I have a good theoretical background in philosophy (logic) and computing. I'm not focused on working on synchronisation, but I am ready to help whenever needed so that I can finally sync my phone(s) with linux as I was able to do with my palm III some 7 years ago. I don't agree that my work on the akonadi plugin for opensync was in vain. The broken libsyncml is showstopper for me but it does not mean that the plugin is unusable in general. This was also my motivation to do it and to complete the functional support for all possible (from opensync perspective) object types. It was also fun and a test for my skills. However your arguments, which I thought myself back then did not allow me to make it much better. I left this "polishing" part for some later version. But this is not the point here. As I couldn't find any useful code to check KDE capability in SyncEvo I asked (AFAIR) but nothing happened. You've just send me the link that did not have any downloadable information. Then I was busy and couldn't investigate further. In short terms I think your project is much more promissing, so let me know where I can find the code and how I can contribute. I'll be able to make a schedule next week and say for sure how much time I can spend ... in any case there will be few hours for evaluation of your work and for supporting you. I think its pretty fine to have and to support competative products (as we are opensource thinking people) kind regards From patrick.ohly at gmx.de Sat Jan 8 19:46:19 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Sat, 08 Jan 2011 20:46:19 +0100 Subject: [SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: <634811.44058.qm@web161202.mail.bf1.yahoo.com> References: <634811.44058.qm@web161202.mail.bf1.yahoo.com> Message-ID: <1294515979.3453.237.camel@pohly-mobl1.ikn.intel.com> On Sa, 2011-01-08 at 12:36 +0000, Emanoil Kotsev wrote: [...] > I don't agree that my work on the akonadi plugin for opensync was in > vain. My apologies if that sounded a bit harsh. My view point is that of a user: which use cases does it satisfy? Can it be installed without too much trouble? Is it production-quality? These are the goals that I have with the stable SyncEvolution releases. > But this is not the point here. As I couldn't find any useful code to > check KDE capability in SyncEvo I asked (AFAIR) but nothing happened. > You've just send me the link that did not have any downloadable > information. There are no binaries with Akonadi support, if that's what you were looking for. It is too early for that. http://saidinesh5.wordpress.com/2010/08/24/are-we-there-yet/ points towards the source code repository where Dinesh does his work: http://gitorious.org/~saidinesh5/meego-middleware/saidinesh5-syncevolution The HACKING document contains some general hints about compiling SyncEvolution and Dinesh describes specific steps for the Akonadi support in his blog post. So if you have time, I suggest that you give compiling it a try, then try it out and work with Dinesh to address any of the known (or unknown) gaps. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at yahoo.com Sat Jan 8 20:42:26 2011 From: deloptes at yahoo.com (Emanoil Kotsev) Date: Sat, 8 Jan 2011 12:42:26 -0800 (PST) Subject: [SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: <1294515979.3453.237.camel@pohly-mobl1.ikn.intel.com> Message-ID: <48897.48513.qm@web161206.mail.bf1.yahoo.com> Hi, --- On Sat, 1/8/11, Patrick Ohly wrote: > My apologies if that sounded a bit harsh. My view point is > that of a > user: which use cases does it satisfy? Can it be installed > without too > much trouble? Is it production-quality? No problem about this, but you lack arguments and one can not understand why you are saying this. I was thinking the same before starting the work, but as nothing in v0.40 is prod. quality I don't care for the qulity of the plugin ATM. The potential I see in it was enough. Also the potential of the opensync framework. The invested time was some hours a day over less then 2 months - I think it's worth for the future and yes it is working very fine (I was surprised too). > > These are the goals that I have with the stable > SyncEvolution releases. I think you are one step ahead of opensync - as I said in the other mail in short terms it is probably a better solution, but as the others said it covers just a fraction of what would be necessary for a real sync solution. However (as I mentioined) I'm ready to put some effort in testing and helping, so that I have a usable solution soon. > > There are no binaries with Akonadi support, if that's what > you were > looking for. It is too early for that. > > http://saidinesh5.wordpress.com/2010/08/24/are-we-there-yet/ > points > towards the source code repository where Dinesh does his > work: > http://gitorious.org/~saidinesh5/meego-middleware/saidinesh5-syncevolution > > The HACKING document contains some general hints about > compiling > SyncEvolution and Dinesh describes specific steps for the > Akonadi > support in his blog post. > > So if you have time, I suggest that you give compiling it a > try, then > try it out and work with Dinesh to address any of the known > (or unknown) > gaps. > I was actually looking for the code. Last time the links I had were not working and there was no akonadi code included. So I couldn't try anything. I'll look forward to have it compiled and installed - probably I'll subscribe your mailing list and for sure I'll give you my feedback. regards From patrick.ohly at gmx.de Sat Jan 8 20:53:29 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Sat, 08 Jan 2011 21:53:29 +0100 Subject: [SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: <48897.48513.qm@web161206.mail.bf1.yahoo.com> References: <48897.48513.qm@web161206.mail.bf1.yahoo.com> Message-ID: <1294520009.3453.259.camel@pohly-mobl1.ikn.intel.com> On Sa, 2011-01-08 at 12:42 -0800, Emanoil Kotsev wrote: > --- On Sat, 1/8/11, Patrick Ohly wrote: > > > My apologies if that sounded a bit harsh. My view point is > > that of a > > user: which use cases does it satisfy? Can it be installed > > without too > > much trouble? Is it production-quality? > > No problem about this, but you lack arguments and one can not > understand why you are saying this. I'm not saying anything, I am asking. Any user looking for a solution should ask them (and several others), and also any developer writing software not just for himself. > I was actually looking for the code. Last time the links I had were > not working and there was no akonadi code included. So I couldn't try > anything. Please not that the "master" branch does not contain the Akonadi backend. You need to check out the "akonadi" branch. Here you can browse the code: http://meego.gitorious.org/~saidinesh5/meego-middleware/saidinesh5-syncevolution/trees/akonadi/src/backends/akonadi -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at yahoo.com Sat Jan 8 21:04:52 2011 From: deloptes at yahoo.com (Emanoil Kotsev) Date: Sat, 8 Jan 2011 13:04:52 -0800 (PST) Subject: [SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: <1294520009.3453.259.camel@pohly-mobl1.ikn.intel.com> Message-ID: <957798.89441.qm@web161206.mail.bf1.yahoo.com> --- On Sat, 1/8/11, Patrick Ohly wrote: > > I'm not saying anything, I am asking. Any user looking for > a solution > should ask them (and several others), and also any > developer writing > software not just for himself. > A: You can sync all of the 4 object types supported by opensync (notes, todos, calendar, events) with any other backend given the plugin for this other backend is working. I leave the cases to your imagination but the number is definitely higher then the number covered by SyncEvolution. Note: the quality is another issue :-) > > Please not that the "master" branch does not contain the > Akonadi > backend. You need to check out the "akonadi" branch. I understood this already the first time, but also the links you've provided were not helpful, or I did not manage it in about 20min to get the code and gave it up. I really tried though. > > Here you can browse the code: > http://meego.gitorious.org/~saidinesh5/meego-middleware/saidinesh5-syncevolution/trees/akonadi/src/backends/akonadi > > The last few emails are helpful. I have the links now, thanks. regards From deloptes at yahoo.com Sat Jan 8 22:41:58 2011 From: deloptes at yahoo.com (Emanoil Kotsev) Date: Sat, 8 Jan 2011 14:41:58 -0800 (PST) Subject: [SyncEvolution] Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: <1294520009.3453.259.camel@pohly-mobl1.ikn.intel.com> Message-ID: <340646.11082.qm@web161208.mail.bf1.yahoo.com> I'm sorry if I'm sending this for aa second time but I've got a strange message So I remember what as the issue the first time I've tried downloading the source code, following http://saidinesh5.wordpress.com/2010/08/24/are-we-there-yet/ this is the problem and the solution developer at lisa:~/SyncEvolution$ cd syncevolution-kde/ developer at lisa:~/SyncEvolution/syncevolution-kde$ git clone git://gitorious.org/~saidinesh5/meego-middleware/saidinesh5-syncevolution.git syncevolution Cloning into syncevolution... remote: Counting objects: 19088, done. remote: Compressing objects: 100% (4975/4975), done. remote: Total 19088 (delta 14380), reused 18432 (delta 13892) Receiving objects: 100% (19088/19088), 5.80 MiB | 1.64 MiB/s, done. Resolving deltas: 100% (14380/14380), done. developer at lisa:~/SyncEvolution/syncevolution-kde$ cd syncevolution developer at lisa:~/SyncEvolution/syncevolution-kde/syncevolution$ git checkout akonadi Branch akonadi set up to track remote branch akonadi from origin. Switched to a new branch 'akonadi' developer at lisa:~/SyncEvolution/syncevolution-kde/syncevolution$ git checkout http://meego.gitorious.org/~saidinesh5/meego-middleware/saidinesh5-syncevolution/trees/akonadi^C developer at lisa:~/SyncEvolution/syncevolution-kde/syncevolution$ cd .. developer at lisa:~/SyncEvolution/syncevolution-kde$ mkdir akonadi developer at lisa:~/SyncEvolution/syncevolution-kde$ cd akonadi/ developer at lisa:~/SyncEvolution/syncevolution-kde/akonadi$ git checkout akonadi fatal: Not a git repository (or any parent up to mount parent ) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). developer at lisa:~/SyncEvolution/syncevolution-kde/akonadi$ git clone git://gitorious.org/~saidinesh5/meego-middleware/saidinesh5-syncevolution.git akonadi Cloning into akonadi... remote: Counting objects: 19088, done. remote: Compressing objects: 100% (4975/4975), done. remote: Total 19088 (delta 14380), reused 18432 (delta 13892) Receiving objects: 100% (19088/19088), 5.80 MiB | 1.67 MiB/s, done. Resolving deltas: 100% (14380/14380), done. developer at lisa:~/SyncEvolution/syncevolution-kde/akonadi$ ls akonadi developer at lisa:~/SyncEvolution/syncevolution-kde/akonadi$ ls akonadi/ AUTHORS ChangeLog HACKING INSTALL-tar-gz LICENSE.txt NEWS README.rst autogen.sh configure-post.in debian docs m4-repo src test COPYING Doxyfile INSTALL LICENSE.LGPL-21 Makefile-gen.am README.packagers SyncEvolution.plist.in build configure-pre.in description gen-autotools.sh po svn2cl.sh regards From deloptes at yahoo.com Sat Jan 8 13:16:22 2011 From: deloptes at yahoo.com (Emanoil Kotsev) Date: Sat, 8 Jan 2011 05:16:22 -0800 (PST) Subject: Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) In-Reply-To: Message-ID: <85304.4430.qm@web161208.mail.bf1.yahoo.com> Hi, thanks for this information I'll try to set it up in near future. thanks again for the links regards --- On Wed, 1/5/11, Dinesh wrote: > From: Dinesh > Subject: Re: Akonadi + KDE support (was: Re: [Opensync-devel] OpenSync: fragmentation is harmful) > To: "Patrick Ohly" > Cc: "Emanoil Kotsev" , "SyncEvolution" , "Sascha Peilicke" > Date: Wednesday, January 5, 2011, 3:21 PM > Hi, > > On 1/5/11, Patrick Ohly > wrote: > > [moving to SyncEvolution list] > > > > On Di, 2011-01-04 at 10:30 -0800, Emanoil Kotsev > wrote: > >> 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 > 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. > > > > I should have mentioned that Dinesh is working on it; > I just haven't > > seen the result yet and don't know whether he wants to > stay around once > > it is included (maintenance!). > > I would be glad to stay around, provided that there is > something for > me to work on :) > > > > >> 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). > > > > Dinesh, is there a chance that Emanoil helps with the > SyncEvolution > > Akonadi backend? I can imagine that the work can be > split up easily (for > > example, you doing the KDE integration (HTTP, KWallet, > GUI), while > > Emanoil does the actual sync backend), but you know > best what the > > current status is. > > Would certainly like to have as much help as we can. > Here is the detailed progress though: > > After the GSoC is over, the only problem left with the > backend was the > KDE specific extensions. The actual sync was working with > both the > HTTP transport and Obex .(As expected ,on second sync, the > KDE > specific fields are wiped out.). > > Syncevolution can now store credentials in? KWallet > backend. > The compilation issues and segmentation faults are > hopefully fixed. > (We are still hard coding values in autotools though :( ) > The Bluedevil plugin is also here. It currently does > exactly what the > Gnome Bluetooth Plugin does, but modifying it to do > something else > shouldn't take much time(Around 1 hour of work) > > The KDE's Notes doesn't yet use akonadi, so syncing notes > is only > tested with just a collection, using akonadiconsole. > > Whats really needed is a GUI and rigorous automated testing > (I used to > test it with my N70 and Ovi server after every change i > made to my > data and haven't yet had any problems though, but that > doesn't mean > there aren't any). > > > Emanoil, attached Dinesh's last email on the subject. > None of his work > > is in the main SyncEvolution. We did one code review a > while back and > > determined that further work was needed to make it > ready. > > I'd be very interested to get as many suitable patches > integrated now. > > 1.2 (= master) is still in an experimental phase, so > modifying core code > > is okay. The Akonadi backend can be modified at any > time, it is just a > > question of when it is ready for users. > > Sascha and I have cleaned up the code as suggested after > that. Also > have removed the libproxy that I have added temporarily, > because of > certain problems that libproxy has with KDE 4.4. I have > tested both > libsoup and libcurl: they seem to be working properly. > > Getting the backend ready is top on my list, then a proper > GUI and may > be after that, adding additional transport agent based on > KIO. > > I was hoping to finish off the KDE specific extensions > first, but > currently am stuck with some weird problem with my > KOrganizer. > The personal deadline i gave myself, is with KDE PIM 4.6, > we should be > able to have a well tested SyncEvolution, atleast the CLI. > I guess with some additional help, i m sure we can reach > that. > > Emanoil, Please test the current backend from my repository > as described in: > http://saidinesh5.wordpress.com/2010/08/24/are-we-there-yet/ > This should give you an overview of how to set things up: > http://blogs.forum.nokia.com/blog/sivan-greenbergs-forum-nokia-blog/2010/11/07/kde-ovi-qt-meego-syncml > > Once after that, you will get to know whats left to do. > > Feel free to ping me on #akonadi-syncml (freenode) or via. > Gmail. > > Regards, > Dinesh > > > -- > > Best Regards, Patrick Ohly > > > > The content of this message is my personal opinion > only and although > > I am an employee of Intel, the statements I make here > in no way > > represent Intel's position on the issue, nor am I > authorized to speak > > on behalf of Intel on this matter. > > > > > From patrick.ohly at gmx.de Tue Jan 4 09:04:39 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Tue, 04 Jan 2011 10:04:39 +0100 Subject: [Opensync-devel] OpenSync: fragmentation is harmful In-Reply-To: <201101031657.13276.g+opensync@cobb.uk.net> References: <1294061572.5803.1175.camel@pohly-mobl1.ikn.intel.com> <201101031657.13276.g+opensync@cobb.uk.net> Message-ID: <1294131879.5803.1286.camel@pohly-mobl1.ikn.intel.com> 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/syncevolution at syncevolution.org/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 -- Patrick.Ohly at gmx.de http://www.estamos.de/ From gollub at b1-systems.de Tue Jan 4 10:36:53 2011 From: gollub at b1-systems.de (Daniel Gollub) Date: Tue, 4 Jan 2011 11:36:53 +0100 Subject: [Opensync-devel] OpenSync: fragmentation is harmful In-Reply-To: <1294131879.5803.1286.camel@pohly-mobl1.ikn.intel.com> References: <1294061572.5803.1175.camel@pohly-mobl1.ikn.intel.com> <201101031657.13276.g+opensync@cobb.uk.net> <1294131879.5803.1286.camel@pohly-mobl1.ikn.intel.com> Message-ID: <201101041136.56798.gollub@b1-systems.de> 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: gollub at b1-systems.de B1 Systems GmbH Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From patrick.ohly at gmx.de Tue Jan 4 11:42:55 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Tue, 04 Jan 2011 12:42:55 +0100 Subject: [Opensync-devel] OpenSync: fragmentation is harmful In-Reply-To: <201101041136.56798.gollub@b1-systems.de> References: <1294061572.5803.1175.camel@pohly-mobl1.ikn.intel.com> <201101031657.13276.g+opensync@cobb.uk.net> <1294131879.5803.1286.camel@pohly-mobl1.ikn.intel.com> <201101041136.56798.gollub@b1-systems.de> Message-ID: <1294141375.5803.1298.camel@pohly-mobl1.ikn.intel.com> 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 -- Patrick.Ohly at gmx.de http://www.estamos.de/ From gollub at b1-systems.de Tue Jan 4 13:11:54 2011 From: gollub at b1-systems.de (Daniel Gollub) Date: Tue, 4 Jan 2011 14:11:54 +0100 Subject: [Opensync-devel] OpenSync: fragmentation is harmful In-Reply-To: <1294141375.5803.1298.camel@pohly-mobl1.ikn.intel.com> References: <1294061572.5803.1175.camel@pohly-mobl1.ikn.intel.com> <201101041136.56798.gollub@b1-systems.de> <1294141375.5803.1298.camel@pohly-mobl1.ikn.intel.com> Message-ID: <201101041411.58373.gollub@b1-systems.de> 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: gollub at b1-systems.de B1 Systems GmbH Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From patrick.ohly at gmx.de Tue Jan 4 13:31:58 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Tue, 04 Jan 2011 14:31:58 +0100 Subject: [Opensync-devel] OpenSync: fragmentation is harmful In-Reply-To: <201101041411.58373.gollub@b1-systems.de> References: <1294061572.5803.1175.camel@pohly-mobl1.ikn.intel.com> <201101041136.56798.gollub@b1-systems.de> <1294141375.5803.1298.camel@pohly-mobl1.ikn.intel.com> <201101041411.58373.gollub@b1-systems.de> Message-ID: <1294147918.5803.1319.camel@pohly-mobl1.ikn.intel.com> 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 -- Patrick.Ohly at gmx.de http://www.estamos.de/ From greve at kolabsys.com Tue Jan 4 10:49:38 2011 From: greve at kolabsys.com (Georg C. F. Greve) Date: Tue, 4 Jan 2011 11:49:38 +0100 Subject: [Opensync-devel] OpenSync: fragmentation is harmful In-Reply-To: <1294131879.5803.1286.camel@pohly-mobl1.ikn.intel.com> References: <1294061572.5803.1175.camel@pohly-mobl1.ikn.intel.com> <201101031657.13276.g+opensync@cobb.uk.net> <1294131879.5803.1286.camel@pohly-mobl1.ikn.intel.com> Message-ID: <201101041149.45376.greve@kolabsys.com> Hi all, On Tuesday 04 January 2011 10.04:39 Patrick Ohly wrote: > 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: FWIW, there are several other projects dealing with synchronization to mobile devices, e.g. Z-Push, which is used by Kolab, Zarafa and Zimbra for synchronization with ActiveSync capable devices. For Kolab, this means you can already use your native Kolab client, otherwise known as KDE Kontact on the notebook and desktop, and have the data synchronized via the server to Android, MeeGo, Symbian, iPhone, Windows Mobile, or even BlackBerry (with a connector). Many of these devices also synchronize with and integrate other data sources, e.g. Google accounts, as does KDE Kontact. But Z-Push is not the only implementation that is being worked on, AFAIK the Horde project is also working on another ActiveSync stack. Simultaneously there is the Syncphony project for Kolab by tarent. And there is of course still Funambol, to which Syncphony also connects. More approaches and projects are likely to exist. So there will be more than one project even after a merge. This is not a major issue, I think, but it is part of the whole picture. This of course does not mean that a merge would not be useful. But what I would be interested in is the direction of the merged project. The appealing part of OpenSync to me was the idea to allow multiple protocols and data pathways and that they do not always necessarily involve a server. While the former part may be too complex, as Patrick pointed out, and the latter may become less important as connectivity gets cheaper, these were interesting goals and the reason I experimented with it several years ago and kept following this list. My understanding of SyncEvolution is that it is based on SyncML only. While incorporating some good ideas, SyncML also has some systematic weaknesses. These are at least in part addressed through the device matrix of SyncEvolution. But at the same time the vendor support seems to be waning, including at Nokia, the previously largest champion of SyncML. So in your mind, would a merged project continue on the SyncML only path, or would there be plans to change the focus of the project to include other protocols? So if you could outline your thoughts on how these things should progress, and what is your vision of the future development, I'd appreciate that very much. Best regards, Georg -- Georg C. F. Greve Chief Executive Officer Kolab Systems AG Z?rich, Switzerland e: greve at kolabsys.com t: +41 78 904 43 33 w: http://kolabsys.com pgp: 86574ACA Georg C. F. Greve -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: This is a digitally signed message part. URL: From patrick.ohly at gmx.de Fri Jan 7 14:12:55 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Fri, 07 Jan 2011 15:12:55 +0100 Subject: SyncEvolution 1.2: downgrade not possible, introduce config versioning Message-ID: <1294409575.3453.25.camel@pohly-mobl1.ikn.intel.com> Hello! Since the beginning it was always possible to switch back and forth between SyncEvolution releases. When backwards-incompatible on-disk changes were necessary, the user had to explicitly asked for them with the --migrate option (needed only once so far, to get the config layout change). For 1.2, this will no longer be possible, because libsynthesis changes its on-disk format ("binfile") in a backwards-incompatible way (can read old format, but old version cannot read new one). On that occasion I also want to make several other changes which will prevent going back: 1. split "type" into independent options, to solve http://bugs.meego.com/show_bug.cgi?id=1023 2. rename "evolutionsource" to "database", "evolutionuser/password" to "backendusername/password", with the old names accepted as alias, but not being written to disk Here's how I intend to handle the transition: * Pre-releases of 1.2 will refuse to do anything with a config unless its complete context gets migrated with "--migrate @"; this will also migrate all configs inside that context. The error message will explain this. Migration happens by renaming ~/.config/syncevolution/default to ~/.config/syncevolution/default.old and then recreating ~/.config/syncevolution/default with the new content. So it will be possible to go back, but only with slow or refresh syncs. * The final 1.2 will do the migration automatically, because most users (in particular those relying on a GUI) will have problems with the pre-release error messages. * I'll introduce .version files in ~/.config/syncevolution, ~/.config/syncevolution/* and ~/.config/syncevolution/*/peers/*. The content are two numbers, one specifying the oldest format definition that the directory is compatible with, the other specifying the current definition. Each SyncEvolution binary needs to check that it's current definition falls into that range, otherwise it is too old and cannot use the config. Using two numbers has the advantage that backwards-compatible extensions are possible. The problem will be that SyncEvolution 1.1.x does not yet check that version. After migrating the configs, it'll fail to find the "type" property. I hope not too many users will fall into that trap. Any comments? Implementation will commence soonish. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.