Re: [Chicken-users] Starting up spiffy for dynamic content

[Kristian Lein-Mathisen]

Hi Norman!

We've been using the vhost-map a lot in our systems too. I've put together
(so far an unofficial) egg that turns spiffy's current-request and
current-response into function arguments and return values respectively.
Maybe that could be useful for some code-samples, if not useful as a
dependency.

https://github.com/Adellica/reser


K.

On Wed, Mar 9, 2016 at 4:01 PM, Norman Gray  wrote:

>
> Peter, hello.
>
> On 8 Mar 2016, at 20:41, Peter Bex wrote:
>
> On Tue, Mar 08, 2016 at 02:48:00PM +, Norman Gray wrote:
>>
>
> So you mean including handlers like:
>>>
>>> (define (vhost-handler cont)
>>> (let ((uri (uri-path (request-uri (current-request)
>>>   (if (string=? (cadr uri) "wibble") ;; we want to handle URIs
>>> like /wibble/...
>>>   (send-response status: 'ok
>>>  body: (format "Good: request was ~S
>>> (vhost)" uri)
>>>  headers: '((content-type text/html)))
>>>   (cont
>>> (vhost-map `((".*" . ,vhost-handler)))
>>>
>>
>> That's how it was intended, yes.  I've added something similar to the
>> wiki with a link to slightly extended (but somewhat outdated) example
>> from a demonstration.
>>
>
> The new section 'A simple dynamic web page example' is perfect, in
> combination with the pointer to the spiffy+sxml example.
>
> I marginally adjusted the linked webserver.scm to use sxml-serializer
> rather than the full-blown sxml transform egg (was that the 'outdated' you
> meant).  I've attached the result.
>
> OK: that's a (very) nice design -- I'll do that.
>>>
>>> But may I suggest that vhost-map is not, perhaps, the best name for
>>> this structure, since the intended functionality is much more
>>> general than mapping vhosts.  As I mentioned, I guessed that might
>>> be a route to the solution, but based on the name, on the fact it's
>>> documented in a section called 'Virtual hosts', and since the
>>> example in that section is about handling virtual hosts, I got the
>>> impression that the author was firmly steering me away from more
>>> open-ended cleverness.  Caolan suggested that I'm not (thankfully)
>>> alone in misinterpreting this.
>>>
>>
>> Well, it is a mapping for which handler to use for which vhost.  That
>> is also the topmost place where dispatching happens for incoming
>> requests, so it's the place where you'd add custom handlers.
>>
>> I could add some intermediate parameter like "request-handler", which
>> then defaults to some procedure that handles the request like the
>> current implementation does (try to serve a file), but it would be
>> one more level of indirection which is basically just what "continue"
>> does now.
>>
>> Would that be sensible?
>>
>
> I don't think that would be necessary and would, as you say, be a further
> level of indirection.  Yesterday afternoon, I did put together a potential
> patch for spiffy.scm which may have the same idea (attached for interest),
> but the vhost-map (once one understands what it's intended for) seems to be
> completely general.
>
> Perhaps dispatch-handler-map, or handler-map, or something like
>>> that, would signal the intent more clearly, along with an example
>>> such as the above.
>>>
>>
>> Not sure that would be much clearer.  Also, it would break compatibility.
>>
>
> Indeed: it's not obvious what the best name is, though 'handle/host'
> seemed to push the right buttons for me.
>
> One would of course export a (define vhost-map fancy-new-name) for
> compatibility.
>
> Since the car of the alist is a host pattern,
>>> then perhaps the word 'host' should be in the name, but in that case
>>> perhaps handle/host might be suitable (and if anything's being
>>> changed, then it might be nice to have a clear catch-all host
>>> pattern, such as #t, or to permit the list elements to be a
>>> continuation thunk as well as a string-thunk pair).  Thus:
>>>
>>> (handle/host
>>> `(,my-general-handler
>>>  ("foo\\.bar\\.com" . ,(lambda (continue) ...))
>>>  (#t . ,my-catch-all-handler))
>>>
>>
>> I think that would only complicate things, and cause more confusion
>> as to the format of this list.
>>
>
> I agree.
>
> It's a wiki, feel free to improve the wording in places where it's
>> unclear.
>>
>
> There's nothing I can usefully add to the change you've made, but I'll
> bear the suggestion in mind for what I expect to be lots of future
> engagement with these docs.
>
> And thanks, Andy, for the pointer to uri-match (and for the mention of
> Knodium, which I intend to investigate further).
>
>
> All the best,
>
> Norman
>
>
> --
> Norman Gray  :  https://nxg.me.uk
> SUPA School of Physics and Astronomy, University of Glasgow, UK
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
>
___
Chicken-users mailing list
Chicken-users@nongnu.org

Re: [Chicken-users] Starting up spiffy for dynamic content

[Norman Gray]

Peter, hello.

On 8 Mar 2016, at 20:41, Peter Bex wrote:


On Tue, Mar 08, 2016 at 02:48:00PM +, Norman Gray wrote:



So you mean including handlers like:

(define (vhost-handler cont)
(let ((uri (uri-path (request-uri (current-request)
  (if (string=? (cadr uri) "wibble") ;; we want to handle URIs
like /wibble/...
  (send-response status: 'ok
 body: (format "Good: request was ~S
(vhost)" uri)
 headers: '((content-type text/html)))
  (cont
(vhost-map `((".*" . ,vhost-handler)))


That's how it was intended, yes.  I've added something similar to the
wiki with a link to slightly extended (but somewhat outdated) example
from a demonstration.


The new section 'A simple dynamic web page example' is perfect, in 
combination with the pointer to the spiffy+sxml example.


I marginally adjusted the linked webserver.scm to use sxml-serializer 
rather than the full-blown sxml transform egg (was that the 'outdated' 
you meant).  I've attached the result.



OK: that's a (very) nice design -- I'll do that.

But may I suggest that vhost-map is not, perhaps, the best name for
this structure, since the intended functionality is much more
general than mapping vhosts.  As I mentioned, I guessed that might
be a route to the solution, but based on the name, on the fact it's
documented in a section called 'Virtual hosts', and since the
example in that section is about handling virtual hosts, I got the
impression that the author was firmly steering me away from more
open-ended cleverness.  Caolan suggested that I'm not (thankfully)
alone in misinterpreting this.


Well, it is a mapping for which handler to use for which vhost.  That
is also the topmost place where dispatching happens for incoming
requests, so it's the place where you'd add custom handlers.

I could add some intermediate parameter like "request-handler", which
then defaults to some procedure that handles the request like the
current implementation does (try to serve a file), but it would be
one more level of indirection which is basically just what "continue"
does now.

Would that be sensible?


I don't think that would be necessary and would, as you say, be a 
further level of indirection.  Yesterday afternoon, I did put together a 
potential patch for spiffy.scm which may have the same idea (attached 
for interest), but the vhost-map (once one understands what it's 
intended for) seems to be completely general.



Perhaps dispatch-handler-map, or handler-map, or something like
that, would signal the intent more clearly, along with an example
such as the above.


Not sure that would be much clearer.  Also, it would break 
compatibility.


Indeed: it's not obvious what the best name is, though 'handle/host' 
seemed to push the right buttons for me.


One would of course export a (define vhost-map fancy-new-name) for 
compatibility.



Since the car of the alist is a host pattern,
then perhaps the word 'host' should be in the name, but in that case
perhaps handle/host might be suitable (and if anything's being
changed, then it might be nice to have a clear catch-all host
pattern, such as #t, or to permit the list elements to be a
continuation thunk as well as a string-thunk pair).  Thus:

(handle/host
`(,my-general-handler
 ("foo\\.bar\\.com" . ,(lambda (continue) ...))
 (#t . ,my-catch-all-handler))


I think that would only complicate things, and cause more confusion
as to the format of this list.


I agree.


It's a wiki, feel free to improve the wording in places where it's
unclear.


There's nothing I can usefully add to the change you've made, but I'll 
bear the suggestion in mind for what I expect to be lots of future 
engagement with these docs.


And thanks, Andy, for the pointer to uri-match (and for the mention of 
Knodium, which I intend to investigate further).


All the best,

Norman


--
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK*** /Data/tools/000-Build/spiffy/spiffy.scm 2016-03-08 11:02:20.0 
+
--- spiffy-with-dispatcher.scm  2016-03-08 13:57:45.0 +
***
*** 35,41 
  ; ticket tracking system (assign tickets to user 'sjamaan'):
  ; http://trac.callcc.org
  
! (module spiffy
(start-server switch-user/group accept-loop
 with-headers send-status send-response send-static-file log-to
 write-logged-response build-error-message
--- 35,41 
  ; ticket tracking system (assign tickets to user 'sjamaan'):
  ; http://trac.callcc.org
  
! (module spiffy-with-dispatcher
(start-server switch-user/group accept-loop
 with-headers send-status send-response send-static-file log-to
 write-logged-response build-error-message
***
*** 47,53 
 default-host vhost-map access-log error-log debug-log
 spiffy-user spiffy-group access-file max-connections
 handle-file handle-directory handle-not-found handle-exception
!handle-access-logging restart-request