[Kde-pim] Review Request: Send payload file name to the client [client side]

[Volker Krause]

> On 2009-02-11 13:34:40, Kevin Krammer wrote:
> > I wonder if it is possible to send some kind of file handle. Sending the file name is a potential race condition, the file can be deleted before the recipient opens it.
> > 
> > Currently a client can rely on getting the full payload when requesting so.
> 
> Andras Mantia wrote:
>     Indeed, there is a problem with this that we should discuss. As of now, it is the client's job to open the file and read the data from it. This can result in the file being deleted or changed in the (although very short) timeframe when the server writes out the data with the filename into the socket and the client reads it and opens the file. As you could see there is no real error check for this case as I don't know what to do if the file is not readable.
>      An idea would be to open the file in the server and send the QFile::handle() (this is not completely portable, WinCE doesn't support it, but I'm not sure we care about). I also couldn't really find how to convert back this handle (int) to a QFile/QIODevice in a portable way. This idea saves our file status, but leaves the closing of the file to the client, which IMO is not good.
>     I'm open to ideas.
> 
> Volker Krause wrote:
>     We could deal with the change case by adding the revision number to the filename. The delete case is a bit more tricky though, maybe we can delay file deletes until the session that requested it has been closed?
> 
> Kevin Krammer wrote:
>     Just to make sure I understand the context correctly: this is not the same issue as using files for caching payloads, this is about avoiding data copying, right?
>     
>     Is this only for reading or also for writing, e.g. when a resource knows that a file is equivalent to one item's serialized form?

Right, this is about avoiding data copying by allowing the clients to read directly from the cache files, and also allowing efficient non-sequential access (eg. my using mmap). This is only for reading, for writing it would be even more complicated to avoid races. For writing, I think streaming the received data directly into a file should be good enough, this avoids a complete copy as well and non-sequential writing is rather uncommon after all.


- Volker


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/55/#review61
-----------------------------------------------------------


On 2009-02-11 13:23:51, Andras Mantia wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/55/
> -----------------------------------------------------------
> 
> (Updated 2009-02-11 13:23:51)
> 
> 
> Review request for KDE PIM.
> 
> 
> Summary
> -------
> 
> This patch extends the client/server protocol in a way that if the client supports direct loading of the payload data from a file, the filename is sent through the socket, not the whole data, thus limiting the amount of data that needs to be transported. This is the client side of the patch.
> I'd like to get feedback especially on the protocol extension.
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdepimlibs/akonadi/item.cpp 924623 
>   trunk/KDE/kdepimlibs/akonadi/itemfetchjob.cpp 924623 
>   trunk/KDE/kdepimlibs/akonadi/itemfetchscope.h 924623 
>   trunk/KDE/kdepimlibs/akonadi/itemfetchscope.cpp 924623 
>   trunk/KDE/kdepimlibs/akonadi/itemfetchscope_p.h 924623 
>   trunk/KDE/kdepimlibs/akonadi/itemserializer.h 924623 
>   trunk/KDE/kdepimlibs/akonadi/itemserializer.cpp 924623 
> 
> Diff: http://reviewboard.kde.org/r/55/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Andras
> 
>

_______________________________________________
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/