Le jeu 03/06/10 18:59, Tommi Mäkitalo [email protected] 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 _______________________________________________ dev-l mailing list [email protected] https://intern.openzim.org/mailman/listinfo/dev-l
