The main thing to keep in mind is that the trie code is mostly undocumented. There is some old documentation here:
http://rmadilo.com/files/docs/devel/tech/urlspace.html My guess is that the best way to address this is to use an internal redirect. The first match would be on PUT and maybe /who/. This filter, which could be written in C, can modify the url. Then the next filter matching will use the new url. >From what I remember, matching is just a cycling through the list of filters so that the first one registered is tested first. Anyway, the first filter could actually trim down the url and set some variables: /who/me/session/abc/something_else becomes /handle_something_else If the path+file handle_something_else exists under pageroot, then you are done! Or, you can register a proc to handle that specific url. If you need more categories after the first, you just insert another filter which matches something below /handle_something_else. So, to summarize, component-level pattern matching where you do everything in one shot, would be difficult to manage. You register filters to handle some number of components, then you use another filter to specialize if necessary. Eventually you can just use a registered_proc. (since it is put, you can't just let it fall through to fastpath). tom jackson On Thursday 29 November 2007 11:56, Rick Cobb wrote: > While we're on the subject of the trie data structures, has there been > any attempt to support component-level pattern matching in these? > > E.g., in a RESTful application, it's often useful to do something like > (making up a Tcl syntax based on the URI-template W3C proposal as I go): > > ns_register_proc -noinherit PUT {/who/{user}/login/{session}} my_proc > $user $session > > In this case, I'd want any PUT to any URL that matched (regex now) > > {^/who/([^/]+)/login/([^/]+}[/]{0,1}$} > > to call my_proc -- and I'd like it to give me those two matched > substrings as arguments. > > We can do these things with ns_register_filter, but it means we do a lot > of string matching in Tcl or our own C/C++ routines rather than in the > tries. > > -- ReC > > -----Original Message----- > From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf > Of Tom Jackson > Sent: Thursday, November 29, 2007 8:52 AM > To: AOLSERVER@LISTSERV.AOL.COM > Subject: Re: [AOLSERVER] ns_unregister_filter > > No, there are code comments which suggest that you can add a filter and > then > delete it before virtual servers are initialized (while there is one > thread), > but all trie structures are read/write no delete after startup. Anything > > having to do with url pattern matching is in this category. > > tom jackson > > On Thursday 29 November 2007 08:10, Ian Harding wrote: > > I know there's no such thing, but is there any way to add/delete > > filters willy-nilly while the server is running? > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[EMAIL PROTECTED]> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > Subject: field of your email blank. > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the > email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
