A look into my twisted mind, and my bizarre design method. To make up for lack of short-term...
posted 23 February 2003
A look into my twisted mind, and my bizarre design method. To make up for lack of short-term memory, I make design decisions by writing down my train of thought -- otherwise I just go in little circles, constantly coming up with the same problems and solutions. The effect is that of a schizophrenic having an argument with himself, which is probably not too far from the truth. An innovation I used in this one was to use indentation to signify a tangent from the main decision-making process; it turned out to be very useful.
- two types of specificity! in the filesystem: this rule applies to all files underneath here, they are all in X = 1 rule: filesystem claims /x, OR = many rulesl: filesystem claims /x/y/z1, /x/y/z2 (silly! converting rules into lots is dumb) BUT then you have the possibility of file-not-founds on a valid claim ( assuming you just convert the claim and then add the path ) - sometimes the file isn't there BUT then you want to give an earlier doc, not root (right???) - yes, you just recurse up the tree BUT how does that work for multiple parents? - doesn't matter: you're given one path, not many AND you might have had a valid response from a less-specific DB claimant e.g. DB takes /bob/ filesystem takes some exceptions in /bob/mary/ (jane and jack) filesystem would always win for bob/mary/* even though DB has them BUT how likely is that scenario? - not very... if it's a few exceptions it would be per file - if it's lots of info, then DB is unlikely to have it anyway SO the filesystem doesn't need to make per-file claims SO how would it resolve two claims for /bob/* from separate locations? - using the ordinary rules of precedence over the two BUT what the /bob/ versus /bob/mary/* situation with files? - well, yeah, you'd end up with a 404 BUT that's not supposed to happen! - true SO some kind of feedback is needed when a claim fails - that would allow lower-scored claims a shot BUT that means our single-winner algorithm is buggered! - yep SO we need to return a scored array of winners SO should this include specificity score? -yes, probably AND what about our search algorithm? - That was based on specificity winning absolutely - Which is no longer the case, so it's buggered. SO the search algorithm should return an array of scored matches! - how do we score specificity over priority? RESULT New algorithm that attempts all valid claims before failing, in order Tweak to make sure results are neither too small nor too large... (and perhaps make these configurable)