________________________________ From: Lachlan Keller <notificati...@github.com> Sent: Sunday, April 23, 2023 23:19 To: ietf-wg-alto/draft-ietf-alto-new-transport <draft-ietf-alto-new-transp...@noreply.github.com> Cc: Subscribed <subscri...@noreply.github.com> Subject: Re: [ietf-wg-alto/draft-ietf-alto-new-transport] Design Complexity (Issue #19)
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. After further discussion, we agreed that providing the metadata is unnecessary for the TIPS protocol. Thus, we will remove the metadata section from the document and, instead, add the capability for the client to request the next recommended edge to consume (option 2 from above), based on the logic described below: In the current version of the draft, after requesting the TIPS view, the client receives a recommended starting edge in the TIPS view summary. The client SHOULD then consume that edge and construct the future URIs based on the sequential nature. This is what allows for the concurrent transmission of updates in HTTP/2 and HTTP/3 in the long polling case, because the client can request multiple at the same time. However, imagine that the client has not polled in a while: Scenario 1: the client requests the next logical incremental URI, but the server has compacted the queue so it no longer exists. Scenario 2: the client hasn't pulled in a long time and thinks it might be better to get a full replacement of the resource. In both these scenarios, the client must take the same following action: Current version w/ full metadata: the client pulls the metadata of the updates graph and calculates the next edge to take (which is presumably the most recent snapshot). The client pulls that edge and then follows the same increment by 1 pattern as before. New Proposed Version: the client requests for the next edge it should pull based on the version tag of the resource it already has and the server provides it with the recommended next-edge URI. The client then pulls that edge using that URI and constructs the future ones from there, following the same increment by 1 pattern as before. — Reply to this email directly, view it on GitHub<https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues/19#issuecomment-1519170814>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA6RQJJAMPFYTOLUFXGV75LXCWMFRANCNFSM6AAAAAAWE4MZRQ>. You are receiving this because you are subscribed to this thread.Message ID: <ietf-wg-alto/draft-ietf-alto-new-transport/issues/19/1519170...@github.com>
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
