[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [GNUnet-developers] New GNUnet publication program

From: Kenneth Almquist
Subject: RE: [GNUnet-developers] New GNUnet publication program
Date: Mon, 14 Sep 2009 11:38:46 -0400

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]