Re: [GNUnet-developers] I concede, GNML can't work (*alone*)

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 25 January 2003 01:49 am, Tom Barnes-Lawrence wrote:
>   So I'm sorry I have to ask (because I find the description heavy
> on implementation details but light on describing the result),
> but does the proposed namespace mechanism:
>
> 1-Allow these directories that are referred to to be rewritten/replaced
>  such that a given namespace reference could return a different chunk
>  of data on different occasions? This no doubt sounds like a stupid
>  question to you, but I really can't tell.

Yes, you can specify that you want to publish updates to a file, but you need 
to decide the question if there will be updates (and how often) once and for 
all when you insert it the first time.

> 2-Allow one user to refer to another user's (or no user's) content from
>  his directory (in the context of a filesystem abstraction, I suppose
>  this would be like making a symlink)?

Yes, you can refer to any content, other users, and no users. Of course, you 
need to know the 'key' to that content in order to refer to it. But whichever 
content you know how to download, you could refer to.

>   I'd also be interested in the idea of it allowing for a moderate
> chunk of text to be associated with each directory- but as it is,
> it seems this one could be pretty straightforward from client-side,
> an approach could be taken similar to those of ftp servers, etc,
> where one file such as README gets sent to the client along with
> the directory listing. This could all be done by simply following
> such a convention in any download client that would display
> directory listings.

Absolutely. The proposal does not detail such high-level client issues. Igor 
wanted at some point some 'special' file in the directory for a 'README' like 
thing, but at the end I think the decision was to refrain from hard-wireing 
this at the low-level that is described in the proposal.

>   Ideally, I'd be happier with both features 1 AND 2, but strictly
> speaking, as long as point 1 was there, the GNML concept becomes
> possible and point 2 (plus the associated text idea) *could* be
> implemented entirely with that.  So as long as point 1 truly is
> a feature of Igor's namespace design, it seems ideal and perfect
> to me and I shall shut up about it.

Note that you don't need a new makeup language, HTML will do fine, all you 
need is a way to encode the GNUnet keys in URLs that will work with most 
browsers (e.g. http://localhost:53535/namespace_in_hex/identifier_in_hex/). 
Then you don't even have to worry about rendering or parsing -- just write a 
proxy a la fproxy. I still have my doubts about the performance of such a 
construction (and if people really want it), but that's a different question. 
In fact, such a proxy may be the *easiest* way to implement a GUI for the 
directories/namespaces.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+MwC89tNtMeXQLkIRAiMSAJ9fCeBp/uusns4KGRrjPSaRYujoWACfSfvm
9jUGxH0av2/9blfcWz6/y3U=
=0/Ha
-----END PGP SIGNATURE-----