KArchive design changes

[Mario Bensi]

> I will use it of course, maintaining code already available in a larger
> codebase is not an option I would totally avoid it, although I hope it will
> go in Qt 5.1+ because otherwise I will have to make my own github repo
> with a copy of it.
> 
> What's you plan for pushing more kdelibs stuff in Qt 5.x guys?
> 
> Anyway I looked at the code from the frameworks branch, the
> tier1/karchive directory doesn't seem to load plugins at runtime
> the way I do. It seems it still has classes such as KTar in the
> library itself, this means that:
>  * each time you want to add support for another archive format you
> need to release another version of the library and third parties won't
> be able to write their plugins (the opposite of, for example, the
> modular design for image support in Qt)

Yes you right in this point. It may be a good idea to add this behaviour in 
karchive for framework. Do you want work on this change ?

>  * applications need to know the format in advance, my implementation
> instead had a public generic API that lets you open a file then it
> detects the mime type and load the appropriate plugin for you.

For this point you can use KFilterDev::KFilterDev(const QString& fileName) to 
use the KCompressionDevice or use findCompressionByFileName(fileName) to get the 
compression type for your file.

Mario