On Tue, 26 Dec 2000, Brandon wrote:
> > They're identical. To get to the latest version of either, you've got to
> > insert a Javascript redirect page.
>
> Well you can use the built-in date-based redirects when I code them (I was
> going to do this yesterday but got distracted by the mailing list). But
> the problem still applies that you have to use a redirect.
No, it doesn't apply, because the redirect can be explicit in the mapkey, ie,
freenet:pigdogjournal// (KSK@pigdogjournal -> autoDateRedirect)
and we immediately have guessable MSKs. See [1] and [2].
> > So in the future, we're also even. So it comes down to which one is better
> > design, and Scott wins. I've got a bit of hacking to do. First, I sleep.
>
> I have a bit of an issue with the format:
> freenet:MSK@[subspace pubkey]/[mapkey]/[document name]
>
> While putting the subspace pubkey in the MSK is an option, it's not
> totally necessary and would be more compact without it. You could instead
> put the pubkey in the mapfile.
Those were my thoughts when I read this proposal. Wait: put the pubkey IN
the mapfile, or specify a SSK w/ pubkey AS the mapfile? No way you mean
the former. That would be really weird. Nah.
> My other nitpick that this syntax requires that the mapkey can't have a
> /. I'd prefer that the document name couldn't have a //.
That makes sense, espcially if non-SSK keys were allowed for mapkey. Not
limiting the mapfile to a SSK makes sense if you want to do sneaky things
like KSK->SVK redirects without confusing the browser (i.e., before real
Freenet plugins are standard).
Actually, even when we have a Freenet plugin that handles redirects
properly, with Scott's proposal we're still going to see the location
change from what we typed, "freenet:KSK@pigdog", to the MSK it redirects
to, "freenet:MSK@asdf/2000-12-27/index.html". Which is damn ugly compared
to typing "freenet:MSK@pigdog//" and having everything happen behind the
scenes where it belongs. That makes me favor your proposal. [2]
> Which would leave us with freenet:MSK@mapkey//documentname, which is what
> I think you were thinking about anyway, but I thought I'd be explicit
> since Scott's proposed syntax differed from this syntax.
Well, yeah, that's what you and I proposed, basically. I'm assuming that
since Scott suggested the MSK@pubkey/mapkey/docname format that limiting
MSKs to SSK mapkeys is The Right Thing, but I don't see why. Yeah, they
are guaranteed updatable and pseudo-updatable, and if we used the // for
the second delimiter, mapkeys could have slashes
("pigdogjournal/2000-12-27") but how does limiting the keytype of the map
make the MSK any more logical? I see MSKs as a legitimate extension of any
key. I mean, all we want to say is "this key is a mapfile" and "look this
up." To me, at least, limiting them to SSKs actually adds confusion.
So now I'm back to my original views, modified by the footnotes below.
[1] I'm in favor of assuming that, in your proposal,
"freenet:MSK@KSK@pigdog//" equals "freenet:MSK@KSK@pigdog//index.html".
Just like web servers. It makes the URI even better than that MTV
Britney-Spears-is-naughty special after footnote 2 is applied to it. You
know the MTV special, the one where they have 13-year-old Blah Blah from
Tennessee criticize Britney's outfit while they zoom in on her tits and
ass. It's a great ploy.
[2] I'm also a proponent of assuming an *implied* "MSK@" if no keytype is
specified. My whole rationale for opposing more complicated things like
"freenet:map:" was that KSK-redirected mapfiles are going to be so common
that other stuff will be annoying to type and do little good. With this
mechanism, "freenet:pigdog//" would imply
"freenet:MSK@KSK@pigdog//index.html" while "freenet:KSK@pigdog//" would be
exactly what is looks like. The 3 people who access KSKs with // in them
will be able to continue to do so with FProxy. The rest of us can enjoy
URIs like "freenet:britneyspears//".
--
Mark Roberts
[EMAIL PROTECTED]
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
