gnunet-developers
[Top][All Lists]
Advanced

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

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


From: Tom Barnes-Lawrence
Subject: [GNUnet-developers] I concede, GNML can't work (*alone*)
Date: Sat, 25 Jan 2003 06:49:54 +0000
User-agent: Mutt/1.3.28i

OK OK, I'm just a big eedjut.

  Every now and again, I come out with something quite moronic. Perhaps
you'd already noticed that! I did.

  I realised a day or 2 ago, that my oh-so-wonderful vision of a web-like
user experience wasn't possible by the means I was describing (the GNML
thing). It *should* have been blindingly obvious to me, that by only
using the existing hash/size/checksum keys to access other content,
you could only access a specific version of that content, hence a set
of such pages could only really form a plain old directed tree structure
rather than a www style net thingy.

  And quite obviously the way that you would want to access the content
in order to allow such a concept, is, big shock, a namespace mechanism.
Like what Igor named his design. But I suppose the thing that got me,
was that whilst the title of Igor's proposal clearly states "namespace",
the actual text of it doesn't *appear* to mention any such thing. True,
it describes a hierarchical filesystem type of an abstraction, but it
doesn't really make clear how it'd be accessed, etc.

  Whilst I obviously can't suggest the GNML concept as any sort of a
*replacement* for the namespace proposal any more, I would still like
to see those primary features of it used in GNUnet.

  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.

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)?



  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.

  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.


  In the meantime, I'm looking into trying to contribute something
client side instead (and something tangible rather than an idea, this
time). I should probably have some sort of progress report in about
a week or 2 (need time for research).

Tom Barnes-Lawrence




reply via email to

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