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!
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
