On Thu, Oct 10, 2002 at 07:40:04AM -0500, Edgar Friendly wrote: > David Allen <[EMAIL PROTECTED]> writes: > > Well I guess that depends on how you look at it. I always thought > > that the mapfile was something of a hashtable, with names as keys and > > CHK's as values. If you look at it like that, it makes no sense that > > the default entry would be returned. Of course I guess there are > > other ways of looking at it. > > > yes, it is very reasonable to look at control documents as being like > a hashtable, where the names are associated with an action (usually > redirecting to another URI, but also possibly a DBR or splitfile). It > all depends on what you mean by 'default', though. Some people > (apparently the writer of that part of fproxy) took default to mean > 'the name to be returned when nothing else matches'. By that frame of > mind, returning it when asked for a nonexistent entry is very > reasonable.
Hm. I think we have very different ways of perceiving this. The name field in the default entry is set to "". The way I thought of this was that if I hit SSK@pubkey/site// then I'm asking for the file "" hanging off of that mapfile, so it makes sense that the default file is named "". The default feature is useful, having a key that acts like index.html does on the web. I just don't think it should bleed over into other areas (arbitrary nonexistant keys) > I'm sure there's websites that redirect you back to the main page when > you 404. I guess we could spec a 'unknown' name in the spec, in > addition to the default, so that freesite authors could redirect > people to their own custom 404 page. But that's getting > complicated. Ah, but on the web, when you get a redirect, that's actually something that your client gets back from the server. (An extra step) In other words, there is a way for your client to tell that it's being redirected. With the default entry, you can tell that the key you requested is being looked up in the mapfile, but unless you inspect the mapfile yourself you can't tell that you're being given possibly bogus information. > > Or look at it the other way - can anybody think of a good reason why > > it should be the way it currently is? How does this suprise the user > > less than returning a DNF or error would when a nonexistent key is > > requested? What value does this provide? > > > Users really don't like errors. For the same reason that IE does > everything it can to either render things reasonably (especially when > that's the wrong thing to do), and then gives really evil error > messages when the user really did screw up, I think it's fine to > return the default entry in a control document. I think that's definately a valid observation, but users also don't like being presented with the wrong information. As a user (and as a programmer) it doesn't make sense that I would request something that I *know* doesn't exist, but it actually returns data. What it comes down to is this - I've made my preference known, I hope others will chime in. Given the pros/cons associated, I think it might be a good idea to specify this in the metadata spec explicitly whichever way is the consensus. -- David Allen http://opop.nols.com/ _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
