Review Request: Adding support to KMimeType for guessing the mimetype by content fetched from an abstract QIODevice

[Friedrich W. H. Kossebau]

Mercredi, le 23 septembre 2009, à 18:33, Friedrich W. H. Kossebau a écrit:
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1696/
> -----------------------------------------------------------
>
> Review request for kdelibs.
>
>
> Summary
> -------
>
> KMimeType already supports the detection of the mimetype from data in the
> working memory. But only using QByteArray as a container class.
>
> Now in Okteta, the hex editor from kdeutils, the data is not stored in some
> continuous memory range, so wrapping it in QByteAray::fromRaw() does not
> work. And creating a data copy just for mimetype detection does not look
> like the smartest solution. Especially, as "KMimeType::findByContent( const
> QByteArray& data )" is just a wrapper to opening a QBuffer buffer on the
> data object and calling "KMimeTypeFactory::findFromContent( QIODevice*
> device, ...)", passing the buffer as device. It would be great it KMimeType
> could do the type guessing for the opened documents in Okteta also based on
> the content, especially as the data is already locally available (same
> addressspace, fast working memory), and writing a dedicated (readonly)
> QIODevice subclass for access is an acceptable overhead IMHO. Others might
> have similar needs, e.g. with files/data streams stored encoded in some
> containers and okay to be decoded on-demand by a QIODevice (only a small
> part of the data might be used, so decoding all of it by default is waste
> of resources). E.g. Ark might have use for it to detect the mimetype of the
> files in archives (currently done only based on the filename).
>
> Attached patch adds two methods, which overload the two mimetype detection
> methods using a QByteArray argument as content with QIODevice argument as
> content provider. For KDE 5 the QByteArray ones might even be removed,
> being the simple, but limited to continuous data wrappers they are.
>
> Okay to commit?

Noone likes to comment this?

There is no new logic contained in this patch, but (just) two more symbols to 
the API, resulting in a more powerful usage of KMimeType due to the abtract 
QIODevice interface which can now be passed as content provider instead of 
only a (local) file or a QByteArray.

So I am considering to simply commit it. But I still would like at least one 
+1 from someone with insight.

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta