cscheid
commented
12 years ago we can have an HTTP interface, as simple as you can imagine. GETting
http://imp.sci.utah.edu:8900/jacob/is/a/poopy/head
would return exactly what you'd expect it to.
If we allow people to post binary blobs (like images) this would be a brain-dead way to share results as they come out of a simulation run, with no additional processing of any kind required. That would be super convenient.
There's other HTTP verbs which we could in theory support, which would turn imp into a real web service (just teach it to respond to HEAD, GET, PUT, and DELETE, and that covers a large portion of our use cases). Not for the first demo, but something to keep in mind.
The shmem interface would be great, but I think we'd get a good chunk of the performance simply by detecting a local connection and switching to Unix sockets. loopback sockets are likely not as fast as shmem, but if I understand them correctly, sockets on both ends share the buffer, so there's one fewer copy. The main thing is that I don't see how to make the metadata work without some kind of socket, and so shmem is just extra complication.
jacobhinkle
waxlamp
I just wanted to state what I have in mind for protocols. Of course we'll have a TCP interface which will probably be ws:// websockets. Whatever that is let's not pigeonhole ourselves: we want to be sure we can easily support it on multiple types of client (besides webbrowsers) and that we can wrap authentication and SSL around it without much fuss.
As for local clients, for obvious performance and space reasons it would be super cool to have a shmem interface, perhaps communicating through unix sockets for the metadata, etc. I have exactly zero idea how to do this, and as long as we're not retards i think we could always solder this back on if we just start with the websockets interface first.
Thoughts?