2 ms·
> "Rather than having some executable sit and wait for data on a TCP socket, it would be nicer to be able to distribute web apps as shared objects: loaded into
by ZenoArrow 10y ago
> "Rather than having some executable sit and wait for data on a TCP socket, it would be nicer to be able to distribute web apps as shared objects: loaded into memory when needed and applied to a request."
How would you know which web app to apply to a request without associating apps with TCP (or UDP) sockets? I'm not saying it can't be done, I'd just like to understand what you're proposing.
- runeks 10y agoI guess one way would be to name your executable/object code appropriately, eg. mywebapp.io.exe, and have what would be a kind of reverse proxy (listening on a socket) open this executable/dll and apply it to incoming requests to mywebapp.io. It's really just associating executables with a host/domain name, isn't it? Of course, it would be nice to serve different resources on the same domain using different executables, but I guess this could work too, if we just define domain->resource->executable routes. It's really just changing the interface from a TCP socket, that a running executable is listening on, to something more sane, like an .so/.dll file which exposes a httpmain() function which accepts a HTTP request as an argument. Then the reverse proxy would be a caller of a function, rather than a dispatcher of data. Then Amazon/Google/MSAzure would have this reverse proxy, which wouldn't be a reverse proxy at all anymore, running on their infrastructure. You would distribute your web app as a Xen image, and the reverse proxy/"web function proxy" would boot up your VM instance on incoming requests, charging for the number of milliseconds the instance runs.