|
From: Emanoil K. <del...@ya...> - 2010-11-03 17:55:29
|
Chris, I've worked on the akonadi stuff last weekend and I think it is good with all objsyncs now. However there are still few issues that are bugging me. Most of all when should I call update and report change and why if I reject a change (forcast sync) it then forgets about the change next time? barry/google/evolution etc all have their own logic, so I don't know what exactly is going on behind those functions Besides I found out in many of them after change_set_data usually *data is freed and sometime also change is freed, however if I free change after data is free I get a free() corruption, which I found is probably related to change holding the pointer (and eventually deleting) - is it true? in the current solution I found out it is better to free the change after reporting it. Also the sync process needs to check id/remoteId not only id or remoteId. I found out setting and using the remoteId field in akonadi is very useful, but it also can lead to multiple items with the same UID. I definitely need to read more about it. regards PS: @Quenting. What is exactly the problem with kitchensync? The same as before or something new? --- On Wed, 10/20/10, Chris Frey <cd...@fo...> wrote: From: Chris Frey <cd...@fo...> Subject: Re: testing and documenting 0.4X To: "Quentin Denis" <que...@gm...> Cc: "Emanoil Kotsev" <del...@ya...>, ewo...@kd... Date: Wednesday, October 20, 2010, 8:13 PM Hi Quentin, Thanks for taking a stab at it. Sorry that you ran into such a roadblock. I'm still swamped this week. I do need to get back to opensync things very soon, but I have 3 or 4 loose end projects that need to be finished first. I think the GUIs are a weak spot in opensync... just like the plugins. Everyone seems to use osynctool if they want reliability. - Chris On Tue, Oct 19, 2010 at 01:38:21PM +0200, Quentin Denis wrote: > Hi guys, > > I am very disappointed to report that removing the friend classes did not help > in fixing the bug. The error remains the same and I am about to give up. My > coding experience is definitely not far reaching enough to debug such an > issue. > > People do not stop checking out and trying the kitchensync SVN, I am afraid of > disappointing those users with this blockage in the development. > > Unless some external contributors will show up, I give you the lot of > kitchensync. Here is my last version: > http://dl.dropbox.com/u/3224566/kitchensync.tar.gz I did not commit it to svn > since it brings no fix. > > Best regards, > Quentin > > > On Sunday 17 October 2010 20:30:13 you wrote: > > On Sat, Oct 16, 2010 at 11:17:47AM +0200, Quentin Denis wrote: > > > Hi Chris, > > > > > How are you doing? I am writing you for a 3 small things: > > Hi Quentin, good to hear from you. I've been busy with Barry, processing > > patches that improve Blackberry support, and reorganizing the library > > code. I've also been distracted by the new Ubuntu release, and > > ran into a file corruption bug in User Mode Linux, so all that has > > taken time away from opensync. :-) > > > > > First, I have a small issue with the google-calendar plugin (the contacts > > > should be ok since they sync successfully between SyncML, akonadi and > > > file- > > > > > sync): > > Thanks for testing google-calendar. Looking at your bug report, it looks > > like the XSLT transform stuff is not yet working. You'll have to > > work with a different plugin until I get a chance to fix that up. > > > > If you only sync calendar items, then I believe google-calendar will > > be more reliable. Contacts probably still need tweaking. > > > > > Second, is possible to add the member/plugin-type in the following > > > output: > > > > > > ObjType: contact > > > > > > Member 2: Adding(0) Modifying(0) Deleting(0) > > > Member 1: Adding(5) Modifying(0) Deleting(0) > > > > > > Let's say somehting like: Member 2 [file-sync]: Adding(0), Modifying(0), > > > ... > > > > I believe it is... it would be in the osynctool code, which would need > > to call osync_member_get_pluginname(). > > > > Are you asking me to change it? :-) Just want to be clear. > > > > > Third, you recommended me to remove the friend statements to fix > > > kitchensync. I had no time in the past weeks to hack again on > > > kitchensync, but suppose I find some time for bigger modification, would > > > you recommend me to write methods like getMember() and setMember() to > > > replace the friend statement? Or are you thinking of a different > > > solution? > > > > Yes, something like that... the other way is to put all such data into > > a struct, and then have one Get() function that returns a constant > > reference to the struct, so it can't be changed. To change it, you'd > > need to use the setMember() functions. > > > > Sort of like this: > > > > struct DataBlob > > { > > string something; > > int setting; > > }; > > > > // then in the main class > > > > class Functionality > > { > > DataBlob m_data; > > > > public: > > const DataBlob& Get() const { return m_data; } > > > > void SetSomething(const string &s) { m_data.something = s; } > > void SetSetting(int s) { m_data.setting = s; } > > > > // and sometimes this even makes sense, if the blob > > // is truly simple data > > void Set(const DataBlob &d) { m_data = d; } > > }; > > > > Sometimes a series of simple get/set functions are are better, instead of > > the struct method, but when porting legacy code that has a lot of public > > variables, sometimes a single Get() that returns a const struct is easier. > > > > The main advantage of get/set code, is that you can look at just the class > > code, and verify that, yes, this code does not leak memory > > or access invalid memory. But if you have public data, or friend classes, > > then you need to look at all the code that accesses the data to make > > sure it is correct... a much harder job. > > > > Of course, sometimes you do need friend classes. I'm not saying to remove > > it where it makes sense... I just seem to recall that 'friend' was used > > in the kitchensync code as a convenience to avoid extra work, which might > > now be coming back to bite us now that the code is large enough that it > > is harder to understand. > > > > Just my $0.02... There are lots of ways to debug things... gdb, valgrind, > > logs... I just like code that is modular, since it makes maintenance > > and programming easier. > > > > - Chris |