On Mon, 25 Dec 2000, Scott G. Miller wrote:
> Keep thinking about it. If you combine SSK and map files (not
> necessarily a hard and fast combination), you can keep the
> implementation very simple by caching a mapfile in fproxy as an
> association to the SSK parent key.
The implementation is simple whether or not we restrict mapfiles to the
SSK parent key. The advantage to your proposal is that we don't corrupt
any of the other keytypes with ugly appendages. The disadvantage is that
we would need to tell FProxy to use the mapfile, because it's not explicit
in the URI. That would require a "Map=yes" attribute in the metadata of
each file that contains any links, because the browser could begin at any
file. That rules out cutting and pasting CHKs from other sources into your
mapfile, at least CHKs that don't have the "Map=yes" attribute set. Once
"Map=yes" is seen for a subspace, every request for data from that
subspace is first checked against the mapfile, and if that fails, then it
is requested normally.
Doing it your way rules out guessable keys. It also rules out
pseudo-updating, but that won't mean very much once real updating is done.
And permanent mapfiles accessed directly from CHKs won't be possible.
These are useful for publications, which would have an updatable key
redirected to a CHK mapfile of each day's issue, so previous issues would
be preserved effortlessly. The lack of guessable keys is the most
disappointing aspect. "freenet:pigdogjournal:/index.html" is a simple,
easy-to-remember key. Without guessable keys, every site is going to have
an KSK "Enter here" page with a button to click or a Javascript redirect.
Your scheme (if I understand it correctly) is unobtrusive and elegant.
Mine is ugly but flexible. Yours is nuch more complicated because of the
key ambiguity. Yet more thinking to be done...
--
Mark Roberts
[EMAIL PROTECTED]
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
