4 ms·

Seeing the need for polling the job status is off putting, especially for a js api that already is using async. If you _need_ to use polling, at least provide a

Seeing the need for polling the job status is off putting, especially for a js api that already is using async. If you _need_ to use polling, at least provide a convenience method I can just await. Better yet, add some signaling to the http api via eventsource or something.

osbre 2y ago
Thank you! We do have one - `runAndWait`. I will shortly update the docs and I agree that using SSE would be more efficient than polling. Will add that next!
- 01HNNWZ0MV43FF 2y ago
  Long polling would be cool!
jjcm 2y ago
Highly prefer and recommend websocket connections for polling. This is what I ended up doing for my side project's video encoding needs[1]. It lets me get silky smooth progress indicators on multiple encoding resolutions at once. [1] https://github.com/jjcm/nonio-video-cdn/blob/master/route/encode.go#L233 https://github.com/jjcm/nonio-video-cdn/blob/master/route/en...
- LoganDark 2y ago
  Do you mean over* polling (instead of polling)? Polling (repeatedly asking the server) and pushing (the server telling you directly) are two different things; polling over WebSocket seems sort of weird.
  - inopinatus 2y ago
    A push over a websocket is still fundamentally a polling behaviour; it’s just happening further down the stack, below the awareness of application code on the client and implemented internally on the server. This does save you an explicit round-trip in your own code though. Ultimately the only element that isn’t polling in a classical machine architecture is the interrupt handler in the top half of the kernel (or system equivalent).
    - LoganDark 2y ago
      Servers doing polling internally and sending you periodic status updates over WebSocket is relatively common. I don't think polling over WebSocket is a good idea in this situation though (as in sending periodic requests to the server asking for a reply).
    - josephg 2y ago
      > A push over a websocket is still fundamentally a polling behaviour; it’s just happening further down the stack, below the awareness of application code on the client and implemented internally on the server. Not necessarily. The server may internally use interprocess signalling or sockets or something to find out when the process is ready instead of busy-waiting. For example, if ffmpeg is run as a child process, the parent process can sleep a thread waiting for the child to terminate. Just about any sort of busy-wait polling behaviour is a code smell in my book. Stop wasting cycles. Let the thing you're waiting on tell you when its ready. If it can't, fix it until it can. This is all opensource code.
      - inopinatus 2y ago
        That will also eventually be polling, within a kernel subsystem or library function that one has merely chosen to perceive as a black box for convenience of reasoning. Seriously, unless you know we’re delivering an interrupt or a signal, assume it’s polling all the way down. And I’m not so sure about the signals.
        josephg 2y ago
        When my program is waiting to read from a network stream, or from a USB device, it uses 0% CPU and responds instantly when the signal comes in. That is how software should be. Maybe there's cases in the kernel where polling is unavoidable. But polling should happen as little as possible - for the sake of both latency and efficiency. I don't spend much time thinking about the kernel. In userland, polling is almost never necessary. I'd love it if just about all software that manages data that changes over time was written such that downstream consumers can be notified when that data changes. This should be the case for filesystems, databases, message queues, web servers, device lists over USB and so on.
- mort96 2y ago
  Eh adding websockets is a significant complexity jump, in my experience it's hard to write websocket client code which doesn't ever end up in a bad state despite connection breaks, and I still haven't figured out how to avoid random long delays in creating a websocket in my own projects. If you only need a completion callback and not continuous progress updates, long polling is an excellent solution which adds very little complexity compared to websockets.
rainbowskys 2y ago
Can you elaborate on what you mean by signaling to the http api?

osbre 2y ago

Thank you! We do have one - `runAndWait`. I will shortly update the docs and I agree that using SSE would be more efficient than polling. Will add that next!

01HNNWZ0MV43FF 2y ago
Long polling would be cool!

jjcm 2y ago

Highly prefer and recommend websocket connections for polling. This is what I ended up doing for my side project's video encoding needs[1]. It lets me get silky smooth progress indicators on multiple encoding resolutions at once. [1] https://github.com/jjcm/nonio-video-cdn/blob/master/route/encode.go#L233 https://github.com/jjcm/nonio-video-cdn/blob/master/route/en...

LoganDark 2y ago
Do you mean over* polling (instead of polling)? Polling (repeatedly asking the server) and pushing (the server telling you directly) are two different things; polling over WebSocket seems sort of weird.
- inopinatus 2y ago
  A push over a websocket is still fundamentally a polling behaviour; it’s just happening further down the stack, below the awareness of application code on the client and implemented internally on the server. This does save you an explicit round-trip in your own code though. Ultimately the only element that isn’t polling in a classical machine architecture is the interrupt handler in the top half of the kernel (or system equivalent).
  - LoganDark 2y ago
    Servers doing polling internally and sending you periodic status updates over WebSocket is relatively common. I don't think polling over WebSocket is a good idea in this situation though (as in sending periodic requests to the server asking for a reply).
  - josephg 2y ago
    > A push over a websocket is still fundamentally a polling behaviour; it’s just happening further down the stack, below the awareness of application code on the client and implemented internally on the server. Not necessarily. The server may internally use interprocess signalling or sockets or something to find out when the process is ready instead of busy-waiting. For example, if ffmpeg is run as a child process, the parent process can sleep a thread waiting for the child to terminate. Just about any sort of busy-wait polling behaviour is a code smell in my book. Stop wasting cycles. Let the thing you're waiting on tell you when its ready. If it can't, fix it until it can. This is all opensource code.
    - inopinatus 2y ago
      That will also eventually be polling, within a kernel subsystem or library function that one has merely chosen to perceive as a black box for convenience of reasoning. Seriously, unless you know we’re delivering an interrupt or a signal, assume it’s polling all the way down. And I’m not so sure about the signals.
      - josephg 2y ago
        When my program is waiting to read from a network stream, or from a USB device, it uses 0% CPU and responds instantly when the signal comes in. That is how software should be. Maybe there's cases in the kernel where polling is unavoidable. But polling should happen as little as possible - for the sake of both latency and efficiency. I don't spend much time thinking about the kernel. In userland, polling is almost never necessary. I'd love it if just about all software that manages data that changes over time was written such that downstream consumers can be notified when that data changes. This should be the case for filesystems, databases, message queues, web servers, device lists over USB and so on.
mort96 2y ago
Eh adding websockets is a significant complexity jump, in my experience it's hard to write websocket client code which doesn't ever end up in a bad state despite connection breaks, and I still haven't figured out how to avoid random long delays in creating a websocket in my own projects. If you only need a completion callback and not continuous progress updates, long polling is an excellent solution which adds very little complexity compared to websockets.

rainbowskys 2y ago

Can you elaborate on what you mean by signaling to the http api?