On Monday 14 September 2009 17:38:46 you wrote: > > 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?
Yes: https://gnunet.org/svn/gnunet/src/include/gnunet_fs_service.h > 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. Right, one should write them to disk. Now, I'm not sure about why you need to generate errors (never good) if higher-leveld dirs don't exist; since this would be all relative to the location of the specification file, we could just create those dirs. > 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. I agree, good thing to remember when writing that code... Best, Christian -- http://grothoff.org/christian/ _______________________________________________ GNUnet-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnunet-developers
