javascript client submodule

[jacobhinkle]

We will need a proof of concept implementation. It would be nice if this is just a super basic plotting tool where we click the x or y axis and can choose a data object from the server (we should also be able to set the address/port for the server interactively). This might be better handled as a separate repo and included as a submodule in imp, so that we can still serve it via http (maybe on a separate port from the imp protocol) by default.

[cscheid]

It's easy to make this as a carefully constructed webpage that requests the right things from the imp server which speaks HTTP. It'd be standard ajax tricks.

[jacobhinkle]

I don't have much experience with python http servers. It sounds like we need to support both persistent and non-persistent connections, and we need to do this depending on the request. For instance like you said it might be good to serve single chunks just like a web address. Is it easier to just run on two ports, one for persistent connections and the other for hangup connections?

[cscheid]

The persistent connections wouldn't be HTTP. We can roll our own simple protocol in that case, on some port.

On some other port, we serve standard HTTP, and there we just use the standard "connect, send verb + data, get result, disconnect" procedure.

I would vote for the following setup. There would be a backend that only speaks unix sockets. Then a "persistent connection server" simply lifts this unix socket to TCP, while an HTTP server talk to our backend in unix-socket-speak, and talks HTTP on the other side. Three processes: one shepherding the data which speaks unix sockets locally, one which speaks HTTP and has short-lived connections, and one which speaks long-lived TCP streams.

[jacobhinkle]

As long as our custom protocol is easy to wrap up with authentication/ssl. I was thinking HTTP plus some other shit for this reason. In particular, if we use a something that just maps a local socket to TCP/IP then are we implementing authentication for the unix socket as well?

it sounds like we should start with the unix socket interface first regardless, and get some prototypes going for server and client. then like you said we use some (presumably existing) layer that converts to TCP/IP, write a networked client (maybe in js or whatever's convenient) and go from there.

[jacobhinkle]

the layer is just socat right?

[cscheid]

Possibly, I don't know about it.

But I'm positive that it must exist, given how basic it is.

On Feb 27, 2012, at 6:57 PM, Jacob Hinkle wrote:

the layer is just socat right?

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[jacobhinkle]

I've never used unix sockets before. Where should we start?