On Mon, 25 Dec 2000, Mark J. Roberts wrote:
> On Mon, 25 Dec 2000, Brandon wrote:
>
> > > Yeah, as long as the link wasn't to the CHK of the map it would
> >
> > I still don't see what the problem you're pointing out is. Can you give a
> > clear example of what wouldn't work?
>
> This problem is a normal recursive paradox with two content hashed files,
> just like trying to make two html files with CHK links to each other: the
> hash of one depends on the hash of the other, and you can't get the hash
> of the other without the hash of the first. That's one reason why I first
> ruled out this idea. But if you redirect through an enumerated SSK key it
> will work.
>
> I still don't know how to implement it this way, with ambiguous URIs. Once
> we read the metadata from "blah.html", and notice the
> MapFile=SSK@blah/blah, how do we remember to use it (and not the normal
> SSK) when the next request comes in from a link or image on that page?
>
> > > work. Date-based enumeration would require setting aside a portion of the
> > > subspace for maps ("/maps/YYYY-MM-DD"). It's a neat short-term hack, but
> > > when we have real updating we're going to have lots of sites updating
> > > hourly, or every 10 minutes, or whatever.
> >
> > No, the enumeration of map files doesn't have to be related to the
> > subspace that you're mapping to at all.
>
> Another subspace? Why bother with another subspace just for map files.
I keep getting more and more confused about what you guys are
proposing. Sigh.
Scott proposed in order to maintain the purity of the keys that all
mapfiles be inserted as the SSK parent key. I wondered how you would tell
which system to use, map files or the subspace, and naively proposed
metadata in each file. But that won't work, because when the user requests
"SSK@5934tu3904t/index.html", there might not even be a SSK "/index.html",
but only a map file, "SSK@5934tu3904t/" that lists "/index.html" as
"CHK@ryr848y32r". The user can't just request the CHK of a file to begin,
because then the browser will be confused because the directory structure
won't necessarily match. One solution would be to allow the user to start
at the map file (the SSK parent key) "SSK@838yr238ry/", request the map
file, and automatically redirect to the first file listed in the map file,
sort of like a web server will redirect to index.html automatically. You
could bolt date-enumerated mapfiles on top of this by defining a special
kind of redirect that automatically redirects to today's date and
inserting it as the parent key. Then, when we read the parent key, we
download the proper mapfile and use it for all subsequent keys within that
subspace. But that solution is also flawed.To tell FProxy that we're using
a map file we're starting off at the map file, and because that map file
is the parent key, the browser is happy. For an hour afterward, while the
map file is cached, we automatically use it. But after it expires we again
assume that it is a regular subspace. That rules out linking to inside a
map-space, bookmarking a map-space, and leaving the browser window open
for an hour and then surfing the map-space.
If we didn't mind corrupting the sanctity of the keys a little, we could
declare that the only valid map files are CHKs, and to request files
within a map file, you have to append them to the CHK after a slash (all
files start with a slash anyway). For example,
freenet:CHK@rE9zY9IVJAqGZInGOF0d03L6ZeoOAwE,nmrAmhCGI3EBnKMALocq7A/index.html
unambiguously tells fproxy to return file "/index.html" within the map
file "freenet:CHK@rE9zY9IVJAqGZInGOF0d03L6ZeoOAwE,nmrAmhCGI3EBnKMALocq7A".
Thing is, these can't be redirected to, so the only real advantage to this
proposal over mine (which uses a character disallowed in all URIs, ":", to
explicitly tell fproxy that the key is a mapped) is that it looks kinda
like a SSK, in that it has no confusing colon.
More thinking to be done...
--
Mark Roberts
[EMAIL PROTECTED]
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
