From kde-pim  Sat Jun 28 18:34:02 2008
From: "Dmitry Ivanov" <vonami () gmail ! com>
Date: Sat, 28 Jun 2008 18:34:02 +0000
To: kde-pim
Subject: Re: [Kde-pim] [PATCH] Akonadi::ItemSync customization
Message-Id: <6df8d8b90806281134j68625be4vb73d6854b970449 () mail ! gmail ! com>
X-MARC-Message: https://marc.info/?l=kde-pim&m=121467807716983

On 6/28/08, Volker Krause <vkrause@kde.org> wrote:
> On Friday 27 June 2008 21:44:07 Kevin Krammer wrote:
>> Hi Dmitry,
>>
>> On Friday 27 June 2008, Dmitry Ivanov wrote:
>> > Hello,
>> >
>> > The attached patch allows to customize the behaviour of
>> > Akonadi::ItemSync:
>> >
>> > 1. Allows subsclasses to "plug in" their own sync algorithms by
>> > reimplementing virtual bool updateItem( const Item &local, Item &remote
>> > )
>> > const
>>
>> I know that "local" and "remote" make sense in the resource context, but I
>> would appreciate names that reflect more precisely that one item is the
>> version already known to Akonadi and the other is the potentially changed
>> one.
>>
>> I specifically renamed similar parameters to other methods because it
>> always confused the hell out of me since if your mental context is the
>> Akonadi connection, "local" indicated "from this process" and "remote"
>> indicated "from the Akonadi server process".
>>
>> Probably more like "stored" or "old" or "current" instead of "local", no
>> idea for "remote" alternatives.
>
> newItem (since new is a keyword)? I agree that local/remote is really
> confusing since the meaning changes depending on your point of view.

Committed in rev 825557, the signature is
bool updateItem( const Item &storedItem, Item &newItem )

>> > 2. Allows to specify how much data ItemSync should fetch from the cache
>> > when building a list of all items for the collection being synchronized,
>> > by calling
>> >    fetchScope() or setFetchScope().
>>
>> One suggestion:
>>
>>  void ItemSync::doStart()
>>  {
>> +  ItemFetchJob* job = new ItemFetchJob( d->mSyncCollection, this );
>> +  job->fetchScope() = d->mFetchScope;
>>
>> IMHO job->setFetchScopr( d->mFetchScope ) would be cleaner.

Fixed.

Dmitry

-- 
A: Because it destroys the flow of the conversation
Q: Why is top-posting bad?
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/