> This is interesting, in part because I recently did a similar split into two > steps for the new 0.9.x FS publishing API. Now, what is not yet possible with > that API is the serialization into a specification file for the end-user > between > the two stages, but that might be a possibility. The main problem I see is > that the new API allows for "files" to be published that are not on disk (the > caller would just have to specify a function for how to get the data); that > kind-of conflicts with the ability to serialize to a human-readable file.
I haven't seen anything about the new API on the web site; do you have a draft written yet? The way I handle files that are not on disk is to write them to files at the same time the specification file is written. Basicly, if you give a specification file name "a/b/c", then the specification is written to that file, and any data that isn't already in files is written to files named "a/b/0001.dat", "a/b/0002.gnd", and so on. In order to make this a bit more convenient to put each specification file in its own directory, the directory "a/b" is created if it does not exist. If higher level directories (such as the directory "a" in "a/b/c") do not exist, that is treated as an error. The other issue with files is that the current working directory of a process which reads a specification file might be different than the current working directory of the program that wrote the file. So relative file names in a specification file are relative to the directory containing the specification file. _________________________________________________________________ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/171222984/direct/01/ _______________________________________________ GNUnet-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnunet-developers
