Mitar

My suggestion would be that: * Subscriptions do not send data, but only URLs of new versions of data available. Client then fetches those using regular GET to obtain versions...

> The offer/fetch doubles round trips. Not with HTTP2, but that is abstracted away from the client.

Please read: * https://en.wikipedia.org/wiki/HTTP/2_Server_Push * https://github.com/dunglas/vulcain

> The client needs to know first what to request in the first place, hence introducing the latency. With HTTP2 the server can proactively push the second response together with...

> This suggestion doesn't prevent the echoes, it just wraps them up in HTTP/2 server-push semantics, and that doesn't address the goals stated in the OP: (1) to reduce bandwidth,...

> It's important to be easy to write new implementations Yea, but they might be slightly sub-optimal. But what is easiest than to: - get a URL from subscribe -...

> That fits the description of this proposal, which adds a Peer: header to both GET+Subscribe, and PUT requests. The server can use this to skip sending back versions that...

> These are real issues that came up in our implementations. We need a solution. This is not theoretical. Doesn't every patch have an unique version associated with it? I...

But there is big difference between "full version history" and "set of seen versions" in how hard is to implement each.

> I think Peer and Skip-Peers are different names for the same thing. The later is a list. Which can also be an empty list if you do maintain robust...