Am Freitag, Juni 04, 2010, 12:31:40 schrieb emmanuel@engelhart.org:
Le jeu 03/06/10 18:59, Tommi Mäkitalo tommi@tntnet.org a écrit:
The solution 1 has really the advantage, that the user can download a
...
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 dev-l@openzim.org https://intern.openzim.org/mailman/listinfo/dev-l
Hi,
this directory solution has the problem, that there is no standard way to access directories. A list of files is easier to handle. Zimlib may even accept a list of files in one string separated by colon like in the PATH variable. Then you could open a zimfile using e.g. "myfile.zim.part1:myfile.zim.part2:myfile.zim.part3". Zimlib may parse the list and use these file names. The advantage is, that the files do not need to be in the same directory. If the filename contains a colon itself (I know one operating system, which do not use mount points but partition names separated by colon like C:\somefile.zim), it may be escaped with a backslash, so passing the file name must be passed as "C:\somefile.zim".
I already implemented yesterday the feature, that zimfile handles multiple parts in a file. It works fine here. Currently I use the naming convention from split but this is easy to change.
And NTFS is widely supported but only on one operating system and not on every device. If you buy a usb stick, it is formatted with fat, which has this 2G or 4G (I don't really know) limitation.
Tommi