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 <[email protected]> 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 [email protected] https://intern.openzim.org/mailman/listinfo/dev-l _______________________________________________ dev-l mailing list [email protected] https://intern.openzim.org/mailman/listinfo/dev-l
