2009-01-30 08:55 |
jnwhiteh
Jim Whitehead II < <jnwhiteh at gmail.com>
On 1/21/09, Yuri Takhteyev <yuri@sims.berkeley.edu> wrote: >> I would argue pretty heavily against doing anything before checking to >> see if the full node exists. I don't see what the above gains us that >> we don't have by swapping 1 and 2. I agree with the overall change in >> strategy. > > I am not sure what you mean. If we switch 1 and 2 then we are > essentially back to where we are right now, unless there is a clear > difference between child_handlers and child_defaults. (If they both > happen after checking the node, then they might as well be merged.) So > there is not change in strategy. Which perhaps is fine. > > I think we need specific use cases before we understand if a change is > worthwhile at this point. If we cannot come up with specific examples > of things that we cannot do with the current design, then I would > stick with what we have for now. To be a bit clearer, hopefully, I'm not sure I understand why we're considering such a change in behavior when we can add parameters like we're discussing without altering the way things currently work. Why do you choose the first level node to check child handlers rather than some other arbitrary level. That is assuming something about the URL structure of the wiki and doesn't seem to make sense. I prefer that the entire node id is always checked first. Its fast and if that node exists I would hope that you'd want to serve it. Failing that we can check the root node and work our way in the chain from left to right. Certainly even this changes the semantics of node processing now but I do not believe we have any cases where this would break anything. My primary disagreement is not checking to see if the full node exists before taking any other action. It's the cheapest thing that we can do and it's the default case in a non-application heavy wiki. Hope that makes sense, - Jim _______________________________________________ Sputnik-list mailing list Sputnik-list@lists.luaforge.net http://lists.luaforge.net/cgi-bin/mailman/listinfo/sputnik-list