It seems to be that this is actually a non-solvable problem.
So we are lost with some drawback anyway we go.
I think we can agree on our goal: using lzma in the future.
So we have to think a scenario that is less probable to make the drawback a problem.
If someone creates an alternate implementation, he will use a library anyway and not going
to implement the algorithm itself.
And my hope is that xz is already portable (actually, I can't think of a reason why it
shouldn't be as it is less hardware dependant as anything else), so the transition
period will be quite short and less hurting than our compatibility break we did just now.
In the end we have to look on what we have: zimreader on Unices, Kiwix on Windows and Ben
NanoNote. If we get it running there it will be fine and usable. That way most used
platforms are backed and when porting to further platform we or the adopters will have
bigger problems to solve when porting zimlib than porting xz.
So I am perfectly confident with that solution.
Could someone from OpenWRT, Qi Hardware and Wikimedia speak up if you see another
problems?
/Manuel
-- Urspr. Mitt. --
Betreff: Re: [openZIM dev-l] Update zim file format in trunk
Von: Tommi Mäkitalo <tommi(a)tntnet.org>
Datum: 26.12.2009 20:55
Am Samstag, 26. Dezember 2009 19:46:36 schrieb Manuel Schneider:
Hi,
I apreciate to see this enthusiastic discussion.
My suggestion is:
* we have lzma and bzip2 support in zimlib
* the zimreader can use both algorithms
* as long as we didn't approve lzma to work on all platforms and systems,
the zimwriter uses bzip2 by default * as soon as we can approve lzma we
switch the zimwriter's default to lzma * for experiments, development,
porting etc. someone who knows what he does he can use lzma anyway * after
the approval of lzma we will wait for some time until we are sure that no
more bzip2-compressed are being made, we drop bzip2-support completely
This way we can make the adoption of lzma smooth. The reader will still be
backwards compatible during the transition period.
Have a nice Christmas,
/Manuel
Sounds reasonable, but the disadvantage is, that it will be more difficult to
create a alternative implementation. At least in the transition period. If
someone wants to create a zim implementation in C# or Java, he must implement
both decompression algorithms. Otherwise he will not be able to read all zim
files.
Tommi
_______________________________________________
dev-l mailing list
dev-l(a)openzim.org
https://intern.openzim.org/mailman/listinfo/dev-l