3 ms·
I wish there were a way to push not just anonymous data/events but http resources, to similar effect. SSE & websockets & http streams can send anonymous data,
by rektide 3y ago
I wish there were a way to push not just anonymous data/events but http resources, to similar effect.
SSE & websockets & http streams can send anonymous data, but I'd like to be able to send an actual thing. As per the most core architecture of the web:
> Axiom 0a: Universality 2.
Any resource of significance should be given a URI. https://www.w3.org/DesignIssues/Axioms.html#uri https://www.w3.org/DesignIssues/Axioms.html#uri
Or alternatively,
> Cool URLs don't change (implicitly, cool things have URLs, see above). https://www.w3.org/Provider/Style/URI https://www.w3.org/Provider/Style/URI
Instead of pushing to a chat app an anonymous blob of json for a chat message to a room, the server could assert a /room/42/msg/c0f3 resource, could identify universally what it is it's sending. The advantage would be so high. It'd become a standard way to assert a resource, to make known a fact, that would be viable across systems. Further http requests to the resource would just work. Folks could link to the resource. How cool it would be if we could send not just data but resources?
We have come glancingly close to getting such a thing so many times. The HyBi mailing list that begat websockets had a number of alternate more resourceful ideas floating around such as a BEEP protocol that allowed patterns beyond request/response of resources. The browser actually implements an internal protocol that uses HTTP2/push to send resourceful messages, web push protocol/RFC8030, https://datatracker.ietf.org/doc/html/rfc8030 https://datatracker.ietf.org/doc/html/rfc8030.
But the underlying http2/push was de-implemented for webserving in general, and even when it was available, it lacked the oft requested ability to get notice of new pushed resources. (https://github.com/whatwg/fetch/issues/65 https://github.com/whatwg/fetch/issues/65 was an old request. https://github.com/whatwg/fetch/issues/607 https://github.com/whatwg/fetch/issues/607 had some steam in making it happen.) Tragic backwards moves in my view, and never acknowledged by blink-dev when protests arose.
The best we have today is to stream json-ls events, which have an @id property identifying them. But developers would have to snoop these events, and store them in a service worker, to make them actually accessible as http resources.
I continue to hold hope eventually we'll get better at using urls to send data, to assert new things happening... But it's been nearly 30 years of me hoping, and with some fleeting exceptions the browser teams have seemed disinterested in making urls cool, in spite of a number of requests. We've been left at un-web side-channels like SSE & Websockets for a long long time now. Wouldn't it be nice to see some real growth for http capabilities that we really can use, that are more than abstract underlying transport tweaks like h2 and h3?