[Qt5-feedback] Fwd: QMimeType

[Иван Комиссаров]

// Forwarding private letters so others can take part in discussion.

Начало переадресованного сообщения:

От: David Faure <faure at kde.org>
Дата: 5 июня 2011 г. 16:32:29 Московское летнее время
Кому: Иван Комиссаров <abbapoh at gmail.com>
Тема: Ответ: QMimeType

On Sunday 05 June 2011, you wrote:
> Hi.
> 
> I don't think it is good idea to start refactoring code again. In fact, it
> seems i only have problem with mimetypes with same extension, however i
> know the way to fix it and it won't take lot of time. 

Well, this has to look at inheritance too, it's not a simple algorithm. See 
the comment above KMimeType::findByUrlHelper for more details.

Also there needs to be a "findByNameAndData" where the data doesn't come from a 
file but from a memory buffer. And the qtcreator code doesn't look into the 
right places for mimetypes, it doesn't follow the xdg base dir spec (but more 
generally this should be provided by e.g. QDesktopServices anyway).

And you're not handling glob-deleteall (__NOGLOBS__ in the globs2 file), which 
is necessary for handling user-defined changes (removing a glob from a 
mimetype).

> I also have lot of
> tests and i'm working for 100% coverage of them. Not sure, but i hope data
> search is correct now.

I strongly suggest to import the tests from 
kdelibs/kdecore/tests/kmimetypetest.cpp

There are also tests about user-defined mimetypes in kde-
runtime/keditfiletype/tests/filetypestest.cpp but these might be harder to port.

> Also, some parts of KDE mime should be entirely rewritten - for example i
> don't think it is good idea to recreate mime type from file each time we
> call KMimeTypeRepository::findMimeTypeByName function.

OK, this could use caching, that's an easy fix.

> Besides, you need do same refactoring as i already done - removing most
> shared pointers to classes, reducing number of interfaces, making code
> more readable (this part is not so important for you as was for me:) )

Yes, the best outcome would probably be your API with my algorithms...

> About functionality - i plan to store mimedatabase bot in binary format
> (for faster loading) and xml (to allow user create own mimetypes/overwrite
> standard one from database). KDE's classes work only with xml with
> separate files and it should be rewritten.

shared-mime-info already generates 'databases' (simple text files) for faster 
glob parsing and magic matching, without the need to parse the xml files. See 
the "globs2" and "magic" files. We only need the xml files for icon and 
comments, but that's not the most common use case.
We should optimize the API for the most common use case, which is "give me the 
mimetype name for this file and/or data". Looking up the details of that 
mimetype (icon, comment, etc.) should only be an optional second step, since 
this requires parsing XML files, while mimetype-matching does not. I did this 
inside KMimeType by parsing the details 'on demand', but we could also do this 
by returning a QString from the "findBy" methods rather than a QMimeType.

I don't think we need a cache in binary format, when there are already caches 
available, pre-generated at install time (so no performance penalty at all for 
generating them while the application is running).

> So, i think there is same amout of work with both classes (you need to
> rewrite some algorithms, i need to cover all tests).

I would rather say, you need to rewrite the algorithms to use "globs2" and 
"magic", and I have the exactly code for that.

> I will be very pleased if you help me with test coverage 

I would be happy to help with tests, but only if I can also change the 
algorithms to use the ones that have proven stable for many years and many 
people. Otherwise I'll have to do my own proposal for mimetypes in Qt, and I 
don't think any of us wants to see duplication of efforts.

> every test makes shows how little i know about mimetypes:)

Hmm :-}

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110605/16425bbd/attachment-0001.html