[Ur] socket detaching

[Adam Chlipala]

On 08/06/2014 03:25 AM, Sergey Mironov wrote:
> I see socket detachment as one possible implementation of file serving
> machine. I didn't measure its performance, I think it has some
> advantages in the field of usability. It allows the programmer
> 1) to access Unix socket for obtaining the system-specific information
> via FFI. I use it to determine client's IP address. AFAIK, we can't
> obtain this information in the vanilla Ur/Web at the moment.

...but I imagine it would be easy enough to add an Ur/Web function to 
get the client's IP address.  Looking directly at the socket feels 
almost like taking advantage of an undocumented implementation detail.  
Such a technique won't produce the proper results with apps compiled for 
CGI or FastCGI.

> 2) consequently, to pass the socket to child processes. File server
> machine is one possible application for that. This way, application
> developer may encode the choice of file server into their application
> (one of my goals - to make installation manual shorter). In the
> urweb-detach demo, I launch bash script to serve the file. Apache may
> be used in place of it.

I just don't see an advantage here over using [returnBlob].  Why involve 
a Bash script or any other external program?  I can see doing 
arbitrarily complicated things to compute a pile of bytes, but I can't 
see why Ur/Web isn't already sufficient to serve said pile to the client.

> Actually, I'm not asking you to include socket detachment, at least in
> its current form. I use it in one project only and I feel I need more
> time to adjust the design. Just wanted to share the idea.

Right, I understand that.  I appreciate the ongoing discussion about the 
best way to design Ur/Web and its FFI facilities!