I'm coming in late and trying to catch up on this. After reading this entire thread I don't get a sense of consensus yet and have to wonder what the rush is. If there is one thing you take away from this message it's slow down and think this through ESPECIALLY if this is going to be added into the core.
I have to agree with Ron about featurities and over-engineering (my term). I'm big on doing the simplest thing possible that works. After scanning this thread and the wiki page I get the sense that the scope is too broad and ambitious which in my experience means it is likely to fail. Even with all forms of pattern matching removed this still seems like a bit much. Let me come at this from a different direction. Is CGI::Application::Dispatch so deficient that it needs to be scrapped or receive a major overhaul? I liked it quite a bit (Nice work Michael. :) because I believe that if you have long complex URLs schemes to manage then you are doing something wrong. (That's my RESTful leanings.) It always did right by me. Besides limitations are fun and good for creativity. (A mantra of the 37 signals team I have to concur with.) Where is the discussion of what you can't do with CGI::Application::Dispatch? Why these missing features are essential (as opposed to nice to have). This isn't clear to me at all. Anyway, these are my initial thoughts. I need to think about this a bit more reading over the wiki page and some of its references. I wanted to put these thoughts out there now since Mark is talking about implementation already. Which brings me back to my first point so I'll stop here. <tim/> --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
