On 12/2/2015 7:47 AM, Jay McCarthy wrote:
Hi George,
The output port (and input port) that a response gets is the real
port, meaning that it has a file-descriptor and can be shared across
places. I suggest having one serve/servlet place that does the
dispatching, forwards the port (perhaps using response/output if you
know the headers and if not, using a new function that I can help you
write) over to another place depending on what the API call is, that
other place does the actual writing, the original place waits for the
completion and then returns (thus closing/recycling the connection).
I'd be happy to look at your code and point you to the internal
functions you might need to write out the response properly.
Jay
Hi Jay,
Thanks for confirming about the port, and also for the offer of help.
In almost all cases the return headers are static: almost all
server->client communication is JSON formatted - regardless of the
disposition of the function call , its wrapping HTTP request succeeds.
Errors (if any) are returned in the JSON data.
But there is one function which returns binary image files. It's
designed to mimic file download so it can be used directly in an HTML
image tag. Might need a spot of help with that one. It currently looks
like:
:
; DBMS fetch image file into 'result'
:
(send/back
(if success
(response/full 200 #"OK"
(current-seconds)
#"application/octet-stream"
'()
`(,result))
(response/full 404 #"REQUESTED OBJECT NOT FOUND"
(current-seconds)
#"application/text"
'()
'())
))
The only other potential difficulty I see would be if a place(d)
function needed to set a cookie on the client. At least for now, none
of the functions I would want to separate need to do that.
I'm going to have to investigate places more and develop a framework on
which to build my (core) distributed version. I have to address some
things like sharing log files [relatively easy I think] and maybe
sharing of a DBMS connection pool. It's an open question whether it's
better to share a connection pool (if possible) among a small number of
multi-threaded places, or to create a large (pool equivalent) number of
single-threaded places each keeping one connection open.
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.