On Tue, Apr 06, 2004 at 09:58:01PM -0400, Kendall Clark wrote: > > > I would like to be able to replace existing sites with Quixote without > > > breaking lots of URLs unnecessarily. In order to do that today, I have > > > to misuse _q_lookup or _q_resolve. That sucks. > > > > I agree. I only disagree that misusing _q_exports is any better a > > solution. > > Sure. We disagree about it being a misuse. That's good to have clear, > at least. Well, maybe not. I don't really see doing the mapping through _q_lookup as a kluge, since it was designed for handling things that didn't fit into _q_export. Is it a kluge to use a facility that was designed to handle less-simple cases to handle your less-simple case? I don't think so. Is it inconvenient enough to deserve consideration? Quite possibly. > I read it. I didn't understand yr _q_map idea, so I didn't follow it > up. Oh, it is simplicity itself. Rather than adding an unobvious kluge to _q_exports, add an interface that is explicitly for mappings. Perhaps _q_map isn't a sufficently obvious name for it? Suppose there were an added interface named _q_map, intended for these connections between URL components and handler objects that don't fit _q_export's simple exposure model, but which are not so complex as to need the generality of _q_lookup. What whould an interface intended for these look like? I'd suggest that it might be a dictionary, which is the natural way of expressing a mapping in Python; it might also provide a better answer than "export lists are usually short, aren't they?" to questions about Quixote's scalability. For the implementation, I have only a handwave about checking this (if present) immediately prior to the point where _q_exports is consulted in the current arrangement. -- We found that we were making mistakes due to the complexity. Then we wrote scripts to write the configs for us, and using these scripts, we made mistakes in a faster, more automated manner. Something needed to be done. -- Jeff Allen, A Gentle Introduction to Cricket