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.

Reply via email to