Re: Push API: not a friend of SPDY

On Mon, Oct 27, 2014 at 09:28:41AM -0700, Martin Thomson wrote:
> On 27 October 2014 08:42,  <rektide@voodoowarez.com> wrote:
> > Anyone who wants to implement a transport can frame it as they please. Building
> > a Push that throws away this information when the message is an HTTP message
> > is something that the lightcone of humanity will hate you for for as long as
> > it holds together. You really really really can not skimp on this because you
> > happen to want other circumstances: if you are building a Push spec for the web,
> > it needs to be able to recieve web-like requsts.
> 
> 
> That's a pretty strong assertion.  Can you provide any justification
> for that?  Any metadata you might want to carry can always be placed
> in a payload after all.

I've already discussed packing into the payload: we have specs such as WAMP which
we can use to pack CALL/RESPONSE messages to a URL into JSON. We could simply
send a valid HTTP response. But how do we get the content-type to know what kind
of packing the message has if we start to communicate with an unknown endpoint? 

This is a spec being built for transfering resources to a user agent. This is
undeniable. But the group right now for whatever reason is focused on sending 
only opaque resources - no content-type, no addressability of the resource being
pushed. 

User agents already receive resources, and when they do those resources are
so called because:
* They have a URL identifying the resource
* They have meta-data describing the conditions of transfer of that resources.

You are the WWW consortium: you should be working to send resourceful resources
to the user -agent. You shouldn't just cram some new telnet protocol v3.0 
(websockets 2.0) into a brand new API in a manner completely decoupled from how
the rest of the web works. 


This work is being done in conjunction with ServiceWorkers, which
themselves are 100.0000000% about resources- yet you are proposing a means of
communicating with them which can not talk resourcefully. Why should ServiceWorkers
have to fill itself with data passed out of band, via means that Push is itself
incapable of equivocating? That seems nonsensical.

I would like the working group to move from pushing messages to pushing resources.
We are here (the w3) because of resources. This spec should move to push resources.
Please respect what is fundamental to the web, and bring Push design more in line
with: http://www.w3.org/DesignIssues/Principles.html


I'd also point out your charter, which says:
"The Web Applications Working Group should adopt, refine and when needed, extend,
existing practices where possible."
Such as the practice of transmitting resources.

Given a couple days of research, I'd also love to point out how using Resources
over opaque messages fulfils this line in in your charter-
"Furthermore, the Web Applications Working Group deliverables must address issues
of accessibility, device independence, internationalization, mobility, privacy,
and security."


My recommendation is for this spec to define optional (perhaps recommended) "url",
and "headers" fields on Push message (domstring/dict), and to rename "data" to 
"body", establishing a convention for resourceful exchange to happen.

If these two steps are done, in addition to fulfilling your charter, I believe the
"Provide Channel" step in 
http://tools.ietf.org/html/draft-thomson-webpush-http2-00#section-2
could be nothing more than a reverse SPDY proxy, which would simplify implementation.
As it stands, it's unclear (to me) what exactly the provided channel constitutes.


Last an apology; I realize I'm probably not well enough in line with the calm
attitude of a working group. Mr Domenic Denicola confirms that in IRC by
saying,
"i don't really want to get involved in that conversation; the OP's vulgar 
attitude makes me think engaging will not be constructive."
And his words express my own thoughts. I feel enormous passions about this
topic, and I have much anxiety about presenting what to me is an obvious,
clear, simple fix with a direct clear and obvious mandate, one which will Move
The Web Forward, which pushes us towards The Web We Want, which arrives us at
a resourceful/web future, and I see such a massive colossal distance that I
feel I will never come anywhere near close to cracking, a distance I cannot
fathom; and this, at least, what I come as, is honest and not overly plucked.
But I am sorry for tracking personal noise into this channel, and I am sorry
for the additional burden I levy by not having the experience, confidence or
connections to better massage my mess of feelings into a manner more appropriate
for this working group's direct consumption. Thank you for attending.


I've To:'d two people who I'd appeal to for help maintaining a web built
of resources, although I'm far from sure they'll agree with the connection I'm
trying to suggest between Push and opaque/web messaging/resouces.

regards, yours,
rektide

Received on Monday, 27 October 2014 18:20:37 UTC