"pattern" urls

james anderson <[email protected]> Tue, 14 Apr 2009 03:10:27 +0200
Newsgroups gmane.lisp.cl-http
Message-ID <[email protected]>
hello;

one of the things i need to do with a lisp http server is to make it  
understand url-namespaces which follow a 'rest' paradigm.
for which some means of url-area management and pattern-based  
concrete-url deconstruction is good.

i recall some discussion of this topic years back, but was not able  
to turn up any complete records. *url-areas* addresses part of the  
problem. the other part is to hook a pattern matcher into the  
response logic. i enclose a file which implements one way to do this,  
but have some concerns about the approach.

my primary concern, is that neither my memory of, nor my re-reading  
of the server code indicates that it is easy to specialize url  
classes. as a consequence, the implementation seems brittle.

  - it relies on the url property list to manage the (pattern x  
response-function) registry. it might be easier to follow and more  
widely useful, if the were implemented in terms of a mixin (then with  
an explicit slot), but it is neither clear where something like this  
should be grafted into the class tree, nor how such alternative url  
classes would be specified when interning.

  - it treats the inferior urls as ephemeral, per-request data. that  
follows what i understood of how search urls are handled. is that  
reasonable?

  - it applies the matching/binding logic in an additional method for  
intern-url-inferior. the chosen specializing class limits the  
usefulness, but again, it was not clear which specialization might be  
preferred.


as a separate matter, it uses cl-ppcre as the pattern matcher. would  
there be any reason to prefer an alternative?


the source is attached below.

_______________________________________________
WWW-CL mailing list
[email protected]
https://lists.csail.mit.edu/mailman/listinfo/www-cl
pattern-url.lisp (application/applefile, 883 B) - not displayed
pattern-url.lisp (application/octet-stream, 11.2 KB) - not displayed