Re: [dispatch] Proposal for Per Resource Events Protocol

[Rahul Gupta <[e-mail]>]

Since mutations can differ for the type of resource, imho it is best to provide a negotiation mechanism instead. Which is what I do in PREP. Intermediaries can then handle mutations as they handle representations.

Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, August 13th, 2023 at 10:54 AM, Michael Toomim <[e-mail]> wrote:


> 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.
> 

> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch