gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] New GNUnet publication program


From: Christian Grothoff
Subject: Re: [GNUnet-developers] New GNUnet publication program
Date: Tue, 15 Sep 2009 09:56:05 +0200
User-agent: KMail/1.12.1 (Linux/2.6.28-grml64; KDE/4.3.1; x86_64; ; )

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/




reply via email to

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