Enable PubSub in the Browser

[daviddias]

Following: #493 (comment)

PubSub will be unavailable as a browser API until https://github.com/ipfs/http-api-spec/issues/116 happens.

[daviddias]

Update on this thread:

We currently have PubSub disabled on the browser as a way to prevent misunderstanding how the cancellation of the API works. Unfortunately, due to what is noted in -- #493 (comment) -- we simply can't cancel requests as go-ipfs expects in the browser. However, it seems to me that removing support for it entirely is not the optimal solution, as for a lot of use cases, only a few amount of PubSub channels will be open from a client, keeping the maintenance of those at bare minimum.

Proposal: enable PubSub and be explicit that cancels aren't actually being canceled, just silenced.

[mitar]

I think we should enable PubSub on client and document cancelation issue.

[Morantron]

I've found and ultra-hacky workaround to cancel fetch requests without XHR here ( https://github.com/Morantron/poor-mans-cancelable-fetch ).

The whole idea is to make requests in a separate WebWorker, and sending a signal to the worker to terminate itself, which also aborts the request

Eventually fetch requests will be able to be aborted ( whatwg/fetch#447 ), but the final API hasn't been decided yet.

I know it's super hackish, but if it works ™️ , it can serve as workaround until fetch requests are abortable.

[mitar]

Great hack! I like it!

[daviddias]

Oh wow! @Morantron wanna submit a PR with that feature? Can you make sure to add a check to see if the browser has WebWorker support?

[Morantron]

@diasdavid Sure! I'm gonna see if I can turn the hack into some kind of FetchController polyfill, and then make the needed changes in js-ipfs-api.

Looks like IE11 does not support fetch, so I guess PubSub won't work given that XHR does not play well with http streams.

[jwahyoung]

Hey, all, hate to ask a potentially obvious (and stupid) question.....but why not just use standard XHR which is cancellable? Believe me, I support the fetch standard and I love what it provides, but if we aren't using a service worker to intercept requests or anything like that, the main difference comes down to error handling.

XHR requests are cancellable and would solve the issue until the fetch standard includes true cancellable requests. The other alternative to this to cancel requests on the client side would be to run a service worker, and have the service worker respond to the request with a 400 Cancelled or something like that when a cancellation is requested. (Basically, you're manually sending a response to an initiated HTTP request to terminate it early.)

[daviddias]

@jedd-ahyoung xhr is not streamable, pubsub/subscribe is a stream. We need to use something like fetch or make this endpoint available Websockets.

[mitar]

Yes, why not websockets? Or dataframes from WebRTC?

[daviddias]

This is not a decision at the level of this client library, it is rather at the http-api spec level. Moving to a complete RPC API where WebSockets is used as a transport has been proposed: https://github.com/ipfs/http-api-spec/issues/116