[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] Namespaces / GNML
Re: [GNUnet-developers] Namespaces / GNML
Mon, 20 Jan 2003 04:51:44 +0000
On Sun, Jan 19, 2003 at 03:16:04PM +0200, Igor Wronsky wrote:
> On Sun, 19 Jan 2003, Tom Barnes-Lawrence wrote:
(Snipped bit about gnunet-gtk, replied separately)
> And about GNML, though I don't personally much oppose it,
I suppose that's at least something.
> Anything with words like "*ml" or "render" in it
> sounds too complicated to me.
Hehe, you sound like my sort of person!
> Besides, anything that in the end requires gnunetd just
> to read/write file blocks can be coded as an external
> client, without gnunet itself knowing anything about what
> goes on with the blocks it transfers.
That was rather the whole point! Back when I was thinking about
this, I didn't really understand much about the workings of
gnunet (well, still don't, it's pretty complicated, the docs are
LONG, and you guys seem to be doing a fine job anyways), and so
wasn't sure what the protocol would be capable of supporting, and
until I saw your namespace proposal on the website, didn't know
that anybody else wanted the same sort of features as I wanted.
So, I tried to come up with something that could just sit on
top and worked like just more files. Besides, it's quite good
to not have to change the network at all to support some new
functionality, no? I'd imagine it would be easier to debug
something when you only have to worry about what one machine is
> However megalomanic
> or insane html/xml/crapml/etc schemes can be built ...
I know what you're getting at, but seriously, I wasn't thinking
about some overblown everything-in-XML mechanism, I was thinking
basically about stripped-down web pages. I wasn't thinking of turning
GNUnet into the next EMACS or anything too convoluted.
The reason for not just using HTML, is that
(1)It depends on an externally supplied program (a browser),
(2)The language is screwed-up by a decade of MS and Netscape
playing embrace-and-extend, so
(3)Most browsers are immense and
(4)Few web-pages are universal with all browsers; but regardless,
(5)HTML uses links that are http:// (or similar) URLs, and we'd want
key+hash+crc links for use with GNUnet (also, the ability for HTML
to access web sites was identified by Freenet as a means to
breach anonymity), and finally
(6)There's the issue of connecting any existing browser anyone
has to GNUnet, ouch.
So in short, the language would have these properties: It would have
probably just enough syntax to allow people to create vaguely structured
documents, hyperlinks to other GNUnet content (no external content!),
images, and have a PGP/GPG signature. The type of tags (and grammar)
available would be limited to make writing a browser for it about as
simple as possible.
It wouldn't even need to be any dialect of SGML or XML or HTML,
it could be an arbitrary format (I'm sure I could knock together a
simple parser for it in Lex+Yacc), it doesn't even need to be called
GNML, it could be called Gnunet Hypertext Format, or Gnunet Web Page,
or something. You could call it Al (call it Al).
> by those who have interests of doing so.
Aha! This sounds like the sort of thing I was expecting to hear
("If you want it, you code it")- I suppose my feeling is, either it
is a good thing, or it is not. If it is good, then regardless of who
thought of it, it ought to be done. If it isn't good, it probably
shouldn't be done, and if no-one else wants it at all, I don't want
to waste god-knows how long trying to write the thing.
I might write a GNML browser, but that is not a promise or even a
commitment, it is a maybe. I don't know if I'm up to it, and we
don't seem to have worked out if it is good or appropriate or not.
I'm not going to say "Someone else write this thing for me that
only I want", either.
> If I read correctly, the only major non-overlapping part is the
> GNML, quite equivalent to the way we were proposing to do a similar
> thing with binary structs?
I was more interested in the functionality, what the end-user
gets. If I read *your* proposal correctly, it supplies a hierarchical
file-system model to the end-user, where the directories have specific
owners, who can link content that they put up into those directories,
and no-one else can put their stuff into that person's directories.
My proposal allows individuals to create simple pages with text
(and possibly images) and links to other content, to say, eg:
"Hello everyone, I am *me*, *here* is some content that I just put
up, *there* is some content that I found, they are files of type foo,
the same as how the search response described them as. BTW I have a
pet goldfish, here is a picture of it, have a nice day".
It doesn't necessarily matter to see who publishes the linked-to
content as much as knowing who vouches for it. And the hypertext
gives another means of communication, in addition to the chat
protocol, see? We could create some sort of GNUnet communities even,
rather than just a bunch of files you can download.
I still like the directories idea, and most of what I understood of
your namespace proposal, I just think there is a subtle difference
between what the two methods *provide*.
> 'Pro-binary' arguments would probably
> include things like efficiency, compactness and ease of parsing.
I wasn't really bothered about binary-vs-text format, for all I
care, your mechanism could use text-based structures and mine could
be some proprietary binary representation. If you look back at my
original posting, you'll see I even suggested .ar files (to allow
inline images to be packaged with the hypertext that uses them).
> Things with *ML are of course much more trendy, buzzword
> compatible, perhaps extendable,
Hell, I don't really get XML, I feel that they are trying to say
that if you use it to do problem Foo, the XML will then magically
create the program that interprets the XML content. I'm no fan
of Java (though I have a few books on it), I can't stand C++, and
feel OOP is 90% dogma. When people talk of Application Servers and
such things, I go "huh?". So please, don't try to make out I'm
one of that sort of crowd, I'm *really* not.
> and you can sell things with them - but for that we'd need
> a gnunet marketing division anyway and we don't have one.
FWIW, I'd be happy to evangelise GNUnet (though I think you're
talking about sell as in business).
> There hasn't been much discussion. Either the proposal is
> too good, or nobody is really interested in it. :)
It is worth noting that not only was the proposal only mentioned
on the site (not the mailing list till I brought it up, AFAIK), but
also the list has been very quiet. Perhaps a few of the people are
busy with something else right now?
Personally, I think your proposal seems very good, and I am
certainly interested in it. I just don't know about *too* good.
PS- Should I be replying to authors and CCing to the list, or replying
to the list, or what? Other people seem to be doing various things.