On Tue, 26 Dec 2000, Brandon wrote:
[snip]
> > freenet:CHK@rE9zY9IVJAqGZInGOF0d03L6ZeoOAwE,nmrAmhCGI3EBnKMALocq7A//index.html
> >
> > freenet:pigdogjournal//index.html
>
> That does look nice and you make a good point. But is a new psuedo-keytype
> all that bad? We might want to define some other psuedo-keytypes later and
> we'll quickly run out of notation. Or maybe we won't. I dunno.
>
> > If you saw how fast I just loaded thirty images across my network, and how
> > damn sexy that // looked (I typed "freenet:mork//index.html" and WHAM!),
> > you would agree with me. That's my opinion, and I'm sticking to it!
>
> Okay, I'll admit that the // does look damn sexy. I mean really, I'm being
> swayed. And you've even implemented it already. I am very tempted.
>
> Argh. I still have the issues of design philosophy. I guess my main
> problem is that I think that this sort of processing should go in a layer
> above the current keytypes so that 1) we don't have to modify the current
> keytypes in order to add this feature, and 2) we can add other such
> capabilities in the higher level, also without modifying the underlying
> keytypes.
As a practical matter, your proposal to put "map:" after "freenet:"
ensures that people who want to access keys like "//a//blah//c" through
FProxy are able to do it.
It also confuses users and adds four characters (including one
hard-to-type character, the colon) to the key.
The "putting 'map:' in there too is good design philosophy" argument isn't
very compelling. I say giving priority to common and useful keytypes is
great design philosophy. The benefit of a very simple way to refer to
map-spaces far outweighs the drawbacks, such as the inability to access
files with really weird names through FProxy, IMHO.
Allowing the omission of the "KSK@" is in a sense bad design philosophy,
because it discriminates against the other keytypes, but the advantages
far outweigh the disadvantages.
> If you have a layer of psuedo-keytypes above the keytypes then each time
> you add a new psuedo-keytype it automatically works with all keytypes and
> each time you add a new keytype it automatically works with all
> psuedo-keytypes.
But how many keytypes and pseudo-keytypes will FProxy need to handle, and
how many of them will be so completely incompatible with our // and useful
as to merit significant concern?
[snip]
--
Mark Roberts
[EMAIL PROTECTED]
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
