ipfs
HTTP API should leverage EventSource Web API
From what I can tell webui keeps polling Daemon REST API, however there is a much better alternative in form of EventSource web API that just keeps connection alive and lets server write push notifications.
It is a very simple alternative to WebSocket API that is easier to adopt and from my point of view makes more sense for the existing REST API, because with websocket you'd need to keep track of inflight requests while combination of POST requests give you tracking for free and EventSource can be used for subscribing to the events hence removing need for memory management.
@Gozala - that looks like an interesting API, though its uni-directional so not appropriate for P2P connections. That documentation you linked to is good on the browser side, but I can't find the server documentation there - i.e. what the format of messages sent by the server is.
@Gozala - that looks like an interesting API, though its uni-directional so not appropriate for P2P connections.
I do agree that it's not appropriate for bidirectional exchanges, however REST API exposed by Daemon is not bidirectional either. I'm might be overlooking something but as I sort of hinted mostly what HTTP API exposes is a way to execute commands, there is no back and forth on it and having live session would just get in the way of it as you'd have to multiplex.
That documentation you linked to is good on the browser side, but I can't find the server documentation there - i.e. what the format of messages sent by the server is.
Here's the link that describes event stream format that server needs to produce.
To clarify I see EventSource useful for things like subscribing to node status updates and for peer stats and possibly file / pin set updates. Possibly for sub part of pubsub. Non of that is bidirectional.
For most other operations I think HTTP PUT / POST is more adequate. Except maybe representing pubsub channel as web socket connection might make more sense, but other than that I'm not sure it would be a better choice.
Thanks @Gozala - glad to see there is now a standard for something I've needed, and cobbled together, many times.
I've been thinking about a neat way of improving things without waiting for /api/v1: perhaps enabling text/event-stream output could be behind an opt-in flag, similar to data-encoding parameter added last year?
(OR client would send Accept: text/event-stream header)
I did some experimentation on this and I have to say that seeing results in network panel is really useful and helpful
Event source API also let's you subscribe to individual event types, which is kind of neat for the pubsub
Unfortunately though if you do issue request with a fetch even with text/event-stream response type, network panel does not seems to render anything:
Related bug in chrome https://bugs.chromium.org/p/chromium/issues/detail?id=1025893