Le jeu 03/06/10 18:59, Tommi Mäkitalo tommi(a)tntnet.org a écrit:
The solution 1 has really the advantage, that the user
can download a
single zim file and split himself when needed. There is even a unix/linux-tool to
split files into pieces named split (isn't it nice how intuitive unix
really is ;-) ).
This seems to me to be the best solution to the >4GB limit of FAT32. But this does
not assigned the problem with option pictures ZIM file etc... But this is maybe
better to consider thus as two different topics.
It is quite easy to extend the iostream to support
multiple files, so that
it internally join the files into one zim file. We just have to think about
the interface, how to tell zimlib which files to join.
As you suggested a naming convention is one possible solution. We may even
use the schema from split. So if you split foo.zim into parts, the parts are
named foo.zimaa, foo.zimab, foo.zimac and so on. If you tell zimlib to open file
foo.zim and it is not found, it looks for the parts until it do not find
any more.
I thing naming convention is not the best solution, I do not like the idea to have
a zimlib depending on filenames. For thousands reasons the ZIM file names may
change.
What about:
*zim::file constructor accepting also directory filename and if directory loads all files
inside and merge them (easy for the app. dev. but a little bit tricky)
*zim::file constructor accepting a list of ZIM file chunks (less handful for the app. dev.
but clean)
Additional question: ist NTFS not widely supported?
Emmanuel