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

[Peter Bex]

On Wed, Mar 09, 2016 at 03:01:56PM +, Norman Gray wrote:
> The new section 'A simple dynamic web page example' is perfect, in
> combination with the pointer to the spiffy+sxml example.

Hi Norman,

Excellent, glad to be of help.

> 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.

I've been rather busy but finally I got around to take a look at it.
That's indeed what I meant by "outdated".  I've taken the code and
replaced the old version with yours.  Thanks a lot!

> 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.

I think the current situation works well enough, so for the moment
I'll leave it as is.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

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 

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

[Andy Bennett]

Hi,

>> Some preconceptions, yes, but I've used enough frameworks such as
>> this to make sure that I keep such preconceptions pretty
>> lightweight, so they're merely a guide as a search for how the
>> system wants to be used.  I thus did find vhost-map quickly, but the
>> documentation appeared to be telling me I was in the wrong place.
> 
> It's a wiki, feel free to improve the wording in places where it's
> unclear.  I've been using Spiffy for too long to see these missing
> pieces.

I also found the request flow and control flow in spiffy quite tricky to
get my head around initially. However, having grokked it, I then went
back to the documentation and couldn't really work out any way of
improving it.

I think a lot of my challenges were around discoverability: spiffy makes
heavy use of parameters rather than procedure arguments which makes
finding out about the state available rather hard.

Once I'd worked out that I could use the vhost-map to override the
default behaviour, creating a "sealed app" became much easier.



Regards,
@ndy

-- 
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0290 DA75 E982 7D99 A51F  E46A 387A 7695 7EBA 75FF




signature.asc
Description: OpenPGP digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

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

[Andy Bennett]

Hi,

> Thanks for these clarifications.
> 
> On 8 Mar 2016, at 12:40, Peter Bex wrote:
> 
>> On Tue, Mar 08, 2016 at 12:02:29PM +, Norman Gray wrote:
>>> It occurred to me that I could/should use the vhost-map to do this
>>> dispatching, using something like
>>>
>>> (vhost-map `((".*" . ,(lambda (continue) ... and ignore (continue)
>>>
>>> But (a) that would clearly be a hack
>>
>> Actually, that's how it was designed to be used.  Not a hack at all!

This is how we do things in Knodium as well and it works a treat.


> Ah!
> 
>>> and (b) it appears that that's designed to be able to re-parameterise
>>> a request, rather than handle it itself,
>>
>> It's intended to be used like that, and you *may* re-parameterise (but
>> that's not necessary).  The idea is that you can create "components"
>> which can be chained together, influencing their sub-components by
>> simply parameterising some options and then passing the flow on to
>> continue.  The last component in the sequence would then actually
>> serve the request.
> 
> 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)))
> 
> OK: that's a (very) nice design -- I'll do that.

We use the uri-match egg to do our routing rather than decomposing the
uri by hand. (http://api.call-cc.org/doc/uri-match )




Regards,
@ndy

-- 
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0290 DA75 E982 7D99 A51F  E46A 387A 7695 7EBA 75FF


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

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

[Peter Bex]

On Tue, Mar 08, 2016 at 02:48:00PM +, Norman Gray wrote:
> Peter, hello.
> 
> Thanks for these clarifications.

You're welcome.

> 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 introduction does mention in passing that you'd add custom path
handlers to the vhost-map.

> 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?

> 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.

> 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.

> Some preconceptions, yes, but I've used enough frameworks such as
> this to make sure that I keep such preconceptions pretty
> lightweight, so they're merely a guide as a search for how the
> system wants to be used.  I thus did find vhost-map quickly, but the
> documentation appeared to be telling me I was in the wrong place.

It's a wiki, feel free to improve the wording in places where it's
unclear.  I've been using Spiffy for too long to see these missing
pieces.

> Thanks again for the illumination.

No problem!

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

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

[Norman Gray]

Peter, hello.

Thanks for these clarifications.

On 8 Mar 2016, at 12:40, Peter Bex wrote:


On Tue, Mar 08, 2016 at 12:02:29PM +, Norman Gray wrote:

It occurred to me that I could/should use the vhost-map to do this
dispatching, using something like

(vhost-map `((".*" . ,(lambda (continue) ... and ignore 
(continue)


But (a) that would clearly be a hack


Actually, that's how it was designed to be used.  Not a hack at all!


Ah!


and (b) it appears that that's designed to be able to re-parameterise
a request, rather than handle it itself,


It's intended to be used like that, and you *may* re-parameterise (but
that's not necessary).  The idea is that you can create "components"
which can be chained together, influencing their sub-components by
simply parameterising some options and then passing the flow on to
continue.  The last component in the sequence would then actually
serve the request.


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)))

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.


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.  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))


The final possibility is to use intarweb directly, but that's
unappealing, since it would require me cut-and-pasting quite a lot
of the content of spiffy.scm.


Now *that* would be a hack ;)


Not half!


Where this is coming from: I'm pretty familiar with the Racket
servlet framework which requires, in serve/servlet
, a
request->response mapping function.

If I'm missing something really obvious, then apologies, and could
someone hand me the clue-stick?


I think you're coming at this from a slightly wrong angle with some
preconceptions that prevent you from using the system as designed,
because you did figure out how to use it (you came up with two valid
solutions to the problem) but rejected them offhand.


Some preconceptions, yes, but I've used enough frameworks such as this 
to make sure that I keep such preconceptions pretty lightweight, so 
they're merely a guide as a search for how the system wants to be used.  
I thus did find vhost-map quickly, but the documentation appeared to be 
telling me I was in the wrong place.


Thanks again for the illumination.

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

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

[Caolan McMahon]

Peter, for what it's worth I encountered exactly the same confusion
when I first used spiffy (or rather, I arrived with the same
preconceptions?). Perhaps this might be fixed by adding a clearly
signposted example to the wiki which demonstrates the recommended way
to implement this kind of dynamic content.

On 8 March 2016 at 12:40, Peter Bex  wrote:
> On Tue, Mar 08, 2016 at 12:02:29PM +, Norman Gray wrote:
>> It occurred to me that I could/should use the vhost-map to do this
>> dispatching, using something like
>>
>> (vhost-map `((".*" . ,(lambda (continue) ... and ignore (continue)
>>
>> But (a) that would clearly be a hack
>
> Actually, that's how it was designed to be used.  Not a hack at all!
>
>> and (b) it appears that that's designed to be able to re-parameterise
>> a request, rather than handle it itself,
>
> It's intended to be used like that, and you *may* re-parameterise (but
> that's not necessary).  The idea is that you can create "components"
> which can be chained together, influencing their sub-components by
> simply parameterising some options and then passing the flow on to
> continue.  The last component in the sequence would then actually
> serve the request.
>
>> so (c) that would clearly be a hack.
>
> Again, that's not a hack but the design.
>
>> Another possibility is to specify the handle-not-found handler, and
>> make sure to start the spiffy server in a context which has no files
>> at all, so that the handle-not-found handler will always be called.
>> But that also feels like a bit of a hack.
>
> That's a bit awkward, but it's an equally valid option.
>
>> The final possibility is to use intarweb directly, but that's
>> unappealing, since it would require me cut-and-pasting quite a lot
>> of the content of spiffy.scm.
>
> Now *that* would be a hack ;)
>
>> Where this is coming from: I'm pretty familiar with the Racket
>> servlet framework which requires, in serve/servlet
>> , a
>> request->response mapping function.
>>
>> If I'm missing something really obvious, then apologies, and could
>> someone hand me the clue-stick?
>
> I think you're coming at this from a slightly wrong angle with some
> preconceptions that prevent you from using the system as designed,
> because you did figure out how to use it (you came up with two valid
> solutions to the problem) but rejected them offhand.
>
> Cheers,
> Peter
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

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

[Peter Bex]

On Tue, Mar 08, 2016 at 12:02:29PM +, Norman Gray wrote:
> It occurred to me that I could/should use the vhost-map to do this
> dispatching, using something like
> 
> (vhost-map `((".*" . ,(lambda (continue) ... and ignore (continue)
> 
> But (a) that would clearly be a hack

Actually, that's how it was designed to be used.  Not a hack at all!

> and (b) it appears that that's designed to be able to re-parameterise
> a request, rather than handle it itself,

It's intended to be used like that, and you *may* re-parameterise (but
that's not necessary).  The idea is that you can create "components"
which can be chained together, influencing their sub-components by
simply parameterising some options and then passing the flow on to
continue.  The last component in the sequence would then actually
serve the request.

> so (c) that would clearly be a hack.

Again, that's not a hack but the design.

> Another possibility is to specify the handle-not-found handler, and
> make sure to start the spiffy server in a context which has no files
> at all, so that the handle-not-found handler will always be called.
> But that also feels like a bit of a hack.

That's a bit awkward, but it's an equally valid option.

> The final possibility is to use intarweb directly, but that's
> unappealing, since it would require me cut-and-pasting quite a lot
> of the content of spiffy.scm.

Now *that* would be a hack ;)

> Where this is coming from: I'm pretty familiar with the Racket
> servlet framework which requires, in serve/servlet
> , a
> request->response mapping function.
> 
> If I'm missing something really obvious, then apologies, and could
> someone hand me the clue-stick?

I think you're coming at this from a slightly wrong angle with some
preconceptions that prevent you from using the system as designed,
because you did figure out how to use it (you came up with two valid
solutions to the problem) but rejected them offhand.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Starting up spiffy for dynamic content

[Norman Gray]

Greetings.

I'm having difficulty working out how to start spiffy, to serve entirely 
dynamic content.  I feel sure I'm missing something really obvious.


I want to serve entirely dynamic content; that is, no static file 
content, but with me supplying code which turns a request structure into 
a response structure.


The spiffy documentation at  
describes clearly how to do all of the configuration necessary to 
configure the server and start it, and mentions in passing that it may 
be necessary to use accept-loop rather than start-server... and so on.


But it doesn't have what I was looking for, namely a description of a 
dispatcher of some type, which might hand off to handler functions 
depending on the structure of the incoming URI, but which would at least 
let me interpose my own handler.  If such a thing exists, I would have 
expected it to be documented in the section 'Starting the server'.


Looking at spiffy.scm, where I'd expect to see this handler is inside 
handle-incoming-request, around where the compiled-vhost-map is 
consulted, or _possibly_ inside process-entry, though the latter appears 
to be very much a filesystem-walker.


If the content of handle-incoming-request included

(handle-exceptions exn
(begin ...)
  (if (dispatcher)
  ((dispatcher) (current-request))
  (let ((host (uri-host (request-uri (current-request)


then the parameter (dispatcher) could naturally take control at this 
point.


It occurred to me that I could/should use the vhost-map to do this 
dispatching, using something like


(vhost-map `((".*" . ,(lambda (continue) ... and ignore (continue)

But (a) that would clearly be a hack, and (b) it appears that that's 
designed to be able to re-parameterise a request, rather than handle it 
itself, so (c) that would clearly be a hack.


Another possibility is to specify the handle-not-found handler, and make 
sure to start the spiffy server in a context which has no files at all, 
so that the handle-not-found handler will always be called.  But that 
also feels like a bit of a hack.


The final possibility is to use intarweb directly, but that's 
unappealing, since it would require me cut-and-pasting quite a lot of 
the content of spiffy.scm.


Where this is coming from: I'm pretty familiar with the Racket servlet 
framework which requires, in serve/servlet 
, a request->response 
mapping function.


If I'm missing something really obvious, then apologies, and could 
someone hand me the clue-stick?


Best wishes,

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