On Wed, 27 Dec 2000, Scott Gregory Miller wrote:
> I'd actually prefer forcing a mapfile to exist in an SVK subspace in order
> to eliminate nesting a key in a key. Thats just ugly in my opinion. The
> advantage to MSK@pubkey,mapname//document was that both mapname and
> document are SSK documents residing under a common SVK public key. In
> other workds, it was a way of defining two keys under one URI without
> nasty embedding.
And as I've said five times before, that also forbids guessable keys that
have paths that work correctly. What users prefer is often not what
programmers prefer. And users want simple guessable keys with no catches.
> On Wed, 27 Dec 2000, Mark J. Roberts wrote:
>
> > On Wed, 27 Dec 2000, Oskar Sandberg wrote:
> >
> > > On Wed, Dec 27, 2000 at 02:00:36PM -0600, Mark J. Roberts wrote:
> > > > On Wed, 27 Dec 2000, Brandon wrote:
> > > >
> > > > > > I need to pass it a Params object because the MapHandler needs to request
> > > > > > the mapfile. Otherwise I can leave getKey alone and do it right in
> > > > > > fillBuckets. Either way is OK IMHO. It's only two lines of code.
> > > > >
> > > > > No, fillBuckets is way too low level. It's a generic piece of code for all
> > > > > keys. You're adding key-specific code and it should go in a key-specific
> > > > > place.
> > > >
> > > > MSKs aren't really keys. They're much higher level than keys.
> > > >
> > > > So where do you suggest I put my one line of code? Whatever I do to
> > > > RequestClient, Oskar will still bite my head off. Ah well...
> > >
> > > Very possibly. I haven't even paid enough attention to figure out what
> > > this whole "MSK" thing is to begin with. When I figure it out I will
> > > probably throw a fit.
> >
> > I'll try to quickly define the proposal. (The discussion was not
> > productive because nobody understood the others' points.)
> >
> > MapSpace Keys
> > =============
> >
> > A MSK is a superior way to insert a Web site. The key is structured as:
> >
> > freenet:MSK@[mapkey]//[filename]
> >
> > [mapkey] is a normally-inserted file under any keytype, and it may be a
> > redirect. It follows the format:
> >
> > Mapfile
> > [filename]=[key]
> > [filename]=[key]
> > ...
> >
> > For example, a chapter of a book might be inserted as:
> >
> > Mapfile
> > index.html=CHK@asdf
> > 01.png=CHK@fdsa
> > 02.png=CHK@qwerty
> > 03.png=CHK@hjhgfsd
> >
> > The contents of the mapfile are cached in a hashtable the first time the
> > mapfile is requested. Subsequent requests for data are thus efficiently
> > looked up.
> >
> > However, keys like "freenet:MSK@KSK@pigdogjournal//index.html" are ugly
> > and hard to type. Two shortcuts were implemented to address this:
> >
> > 1) When the KSK@ is omitted, as is currently allowed, any key with a
> > double slash is assumed to be a MSK. For example,
> > "freenet:pigdogjournal//index.html" is a MSK with a mapfile of
> > "KSK@pigdogjournal", while "freenet:KSK@pigdogjournal//index.html" is a
> > regular KSK. Considering how few KSKs contain double slashes, I believe
> > this is an indispensible shortcut.
> >
> > 2) When the filename is omitted, it is assumed to be "index.html",
> > like a Web server does. We can thus represent the vast majority of MSKs as
> > keys like "freenet:pigdogjournal//".
> >
> > When combined with our new automatic SSK date-updating redirects, this
> > proposal as a whole enables the insertion of updated, guessable, and
> > simple Web sites. Furthermore, it decreases the thousands of individual
> > SSK redirects necessary to insert for a large site (like the Pigdog
> > Journal) to only one. This enables content producers to update their sites
> > virtually as often as they like, to be accessed through simple URIs.
> >
> > That's my proposal, that's my implementation, and I'm sticking to it!
> >
> >
> > --
> > Mark Roberts
> > [EMAIL PROTECTED]
> >
> >
> > _______________________________________________
> > Freenet-dev mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/mailman/listinfo/freenet-dev
> >
> >
>
>
> _______________________________________________
> Freenet-dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--
Mark Roberts
[EMAIL PROTECTED]
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
