3 ms·

I may end up re-thinking this, but one idea was that you could temporarily `tail -f` a log file into a pipe and then check up on it later via a mobile browser.

I may end up re-thinking this, but one idea was that you could temporarily `tail -f` a log file into a pipe and then check up on it later via a mobile browser. It could be writing the whole time, but just dropping everything when you weren't watching it. It would probably also make more sense if I were to add some kind of buffering or storage in the future.

0db532a0 8y ago
I don’t know your needs and goals, and maybe it has to be HTTP, but what about handling the sockets yourself? People could then use netcat to send and receive, and the server could block either end until someone connects on the other end. Personally I would really appreciate a tool I could connect to with netcat or anything else that speaks TCP. I don’t know how someone would use the service from javascript though. No buffering needed by the server. If either end has to be asynchronous, just run in background + nohup if you’re calling this from a shell. Maybe some inspiration from how blocking FIFOs work on Linux: http://man7.org/linux/man-pages/man7/fifo.7.html http://man7.org/linux/man-pages/man7/fifo.7.html You could even do a non-blocking version which just refuses connection. netcat can be set to retry: https://unix.stackexchange.com/questions/432249/nc-to-retry-on-connection-refuse https://unix.stackexchange.com/questions/432249/nc-to-retry-... I realise that this doesn’t make it easy to indicate which pipe one wants to connect to.
- pyinthesky 8y ago
  I think you are right actually. I will experiment with some ways to make blocking vs non-blocking operations. I need to try out @paulddraper's suggestion below to see if I can do that over http. I'd like to make a raw socket version regardless. Like you said, I just need to figure out the best way to pass the key. Edit: One nice thing about the https interface is that you get an encrypted channel. Maybe SSH would be another option for transport. That would also make passing keys easier.
  - 0db532a0 8y ago
    How would the SSH work?

0db532a0 8y ago

I don’t know your needs and goals, and maybe it has to be HTTP, but what about handling the sockets yourself? People could then use netcat to send and receive, and the server could block either end until someone connects on the other end. Personally I would really appreciate a tool I could connect to with netcat or anything else that speaks TCP. I don’t know how someone would use the service from javascript though. No buffering needed by the server. If either end has to be asynchronous, just run in background + nohup if you’re calling this from a shell. Maybe some inspiration from how blocking FIFOs work on Linux: http://man7.org/linux/man-pages/man7/fifo.7.html http://man7.org/linux/man-pages/man7/fifo.7.html You could even do a non-blocking version which just refuses connection. netcat can be set to retry: https://unix.stackexchange.com/questions/432249/nc-to-retry-on-connection-refuse https://unix.stackexchange.com/questions/432249/nc-to-retry-... I realise that this doesn’t make it easy to indicate which pipe one wants to connect to.

pyinthesky 8y ago
I think you are right actually. I will experiment with some ways to make blocking vs non-blocking operations. I need to try out @paulddraper's suggestion below to see if I can do that over http. I'd like to make a raw socket version regardless. Like you said, I just need to figure out the best way to pass the key. Edit: One nice thing about the https interface is that you get an encrypted channel. Maybe SSH would be another option for transport. That would also make passing keys easier.
- 0db532a0 8y ago
  How would the SSH work?