KArchive design changes

[Pier Luigi]

2012/8/24 Mario Bensi <mbensi at ipsquad.net>:
> Hi,
>
> I have check the code and i think we have done a similar work on kde
> framework. I think you can use this instead of your fork to avoid to work on 2
> base of code. If you have any questions to know how use karchive in framework,
> don't hesitate to ask me.
>
> Best Regards
> Mario

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)
 * 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.

Maybe I'm looking at the old implementation, is there another place to look at?

-- 
Out of the box experience
http://www.maui-project.org/