[Kde-pim] Akonadi Fetching full payload of an item after it is partly fetched.

[Volker Krause]

On Saturday 17 May 2008 01:41:24 Tom Albers wrote:
> Kevin found out yesterday that when an item is partly fetched (headers),  a
> subsequent itemfetchjob to get the full payload fails. I've spent some
> hours tracking that down further. In the end it looks like this:
>
> This is send to the server:
> Akonadi::ItemFetchJobPrivate::startFetchJob: Command "10 UID FETCH 416
> FULLPAYLOAD (UID REMOTEID FLAGS)
>
> This is returned:
> mailody(21876) Akonadi::JobPrivate::handleResponse: "*" "416 FETCH (UID 416
> REV 1 REMOTEID "INBOX-+-776" MIMETYPE "message/rfc822" FLAGS (\Seen)
> ENVELOPE {202} and it then returns the headers.
>
> In between there is the akonadi server. It reaches a part that reads:
> server/src/handler/fetch.cpp
>       } else if ( buffer == AKONADI_PARAM_FULLPAYLOAD ) {
>         mAllParts = true; // ### temporary;
>         mAttrList << "RFC822"; // HACK: temporary workaround until we have
> support for detecting the availability of the full payload in the server }
>
> Does this ring a bell for anyone? If not I'll continue to track it down
> further as far as I can.

Fixed in revision 808811, it was caused by a command parsing bug in the fetch 
handler.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080517/d7c93a2f/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/