Re: [Opensync-devel] testing and documenting 0.4X

[Emanoil K. <del...@ya...>]

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