search

jacobhinkle / imp

scientific data server
2 stars 0 forks source link

javascript client submodule #6

Open jacobhinkle opened 12 years ago

jacobhinkle commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

the layer is just socat right?

cscheid commented 12 years ago

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: https://github.com/jacobhinkle/imp/issues/6#issuecomment-4206419

jacobhinkle commented 12 years ago

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