On Sun, 24 Dec 2000, Travis Bemann wrote:
> On Sun, Dec 24, 2000 at 07:06:02PM -0600, Mark J. Roberts wrote:
> > (I wrote up the following this morning, and I still don't see any obvious
> > flaws, so I'll subject it to your criticism.)
> >
> > A map file is a list containing two columns, an absolute filename and a
> > CHK. For example:
> >
> > Mapfile
> > /images/duck.gif freenet:CHK@ABC
> > /chapter_01/index.html freenet:CHK@DEF
> > /chapter_01/cat.jpg freenet:GHI
> > /warez/photoshop.zip freenet:CHK@JKL
> > /blah.html freenet:CHK@MNO
> >
> > The map file is inserted under any key. Most map files will be small
> > enough to insert directly within a non-CHK key. Really big ones may be
> > accessed directly from CHKs (as can smaller ones, of course, which may be
> > desirable for increased security) or redirected to from other keytypes.
> >
> > We must delimit the filename with a character that's not permitted in any
> > key. I vote for the colon, because the "@" and the comma are used in the
> > body of the key, while the colon merely separates the "freenet:" from the
> > actual key. For example,
> >
>"freenet:CHK@rE9zY9IVJAqGZInGOF0d03L6ZeoOAwE,nmrAmhCGI3EBnKMALocq7A:/images/duck.gif",
> > "freenet:SSK@2tDoEptUv7jxljM2pF2mwABsswsQAgE/10-24-2000:/images/duck.gif",
> > and even (especially!) the elegant and guessable
> > "freenet:markjroberts:/images/duck.gif" would be valid keys. I believe
> > the slash after the colon is required so the browser knows what's up
> > (otherwise, it's superfluous).
> >
> > FProxy downloads the map file. It looks up the filename after the
> > delimiter and requests and returns its CHK. Finally, it caches the map
> > file for a reasonable amount of time, maybe one hour. (If the map is
> > accessed again, the time limit resets.)
> >
> > This is really easy to implement, and it's a great improvement over
> > redirecting from a SSK for every single file. It permits guessable keys to
> > be used for file hierarchies without a Javascript redirect. Furthermore,
> > when updating is implemented, a mapped file hierarchy could be easily
> > implemented on top of an updatable SVK. Only one file would need to be
> > updated, as opposed to every file in a SSK hierarchy. This saves time for
> > the inserter, enhances reliability, and avoids unnecessary reliance on the
> > updating mechanism (you just update the map file with new CHKs).
>
> This is suboptimal to a subspace because files can be added later to a
> subspace, while all the files have to already be specified for this
> (but they don't have to *exist* yet).
True, but without real file updating you can't notify the user of any
additions, so they're practically useless. If we can update the map file
directly, we can do whatever we want to the site. While updating is still
vaporware, we can use a new map file every day with a incremented date
SSK. This would be a great improvement over the current system, where you
have to insert perhaps hundreds of individual redirects per
update. Instead, you just insert the new map file. This allows for much
shorter intervals between updates -- while it's infeasible to insert 1000
redirects every 10 minutes, inserting one map file every 10 minutes is
easy.
Mr. Bad found out how hard it is to update a subspace containing thousands
of files. With map files, his once formidable task is trivial. And his
site would load quicker!
--
Mark Roberts
[EMAIL PROTECTED]
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
