Re: [dispatch] Proposal for Per Resource Events Protocol

[Michael Toomim <[e-mail]>]

I want to second this point made by Dale:

> However, it looks like you don't specify what the notifications (the
> body parts of the multipart) will look like.  That may be intended or
> even necessary for this specification, but it means that every
> implementation for an object has to design what its notifications will
> look like.  As Mnot says, that's a negative:  "Intermediaries can't
> understand application-specific semantics, so they can't add much value
> to them without making some big assumptions."

This is why I think it's much more valuable to go all the way, and 
standardize how mutations occur, rather than just provide a generic 
event stream.

Consider that right now, CDNs can only cache a website's static assets. 
All the dynamic state runs over a WebSocket, and the CDN can't store it.

But by standardizing mutations to state, we can have CDNs that 
understand when state changes, and can maintain the current value.

This lets us solve one of the "hardest problems in computer science" — 
dirtying caches. We no longer have to mess with max-age headers. We no 
longer have to force-reload our caches, or add webhooks to tell the CDN 
when it needs to refresh our assets. The CDN can just watch the mutation 
stream, and update itself automatically, in real-time, without any 
additional instruction.