Hi Lachlan, Brief replies inline. I'm concentrating on the high-level points.
On Tue, Apr 11, 2023, at 05:37, Lachlan Keller wrote: >> The first of my issues makes me wonder if this has been implemented at all. >> And >> as I went through this, I found myself asking that same question again >> multiple >> times. Has it? > > LACHLAN: It has been implemented with client pull functionality in > https://github.com/openalto/alto which is an ALTO server using > HTTP/1.1. Server push functionality has not been implemented. That really doesn't count. If the goal is to use server push, then you need to use it. > LACHLAN: As a group, we authors have had many discussions about this, > due to server push’s lack-of-adoption, but as it is a feature of HTTP > that does look to be extremely useful in the case of ALTO, we feel it > makes sense to include support for this feature in this domain specific > case. If indeed it is the case that server push becomes obsoleted, > Section 6 (which defines Client Pull of incremental updates) provides > an equally valid alternative to Server Push defined in Section 7. That makes me question the decision to standardize. No matter how good something is in theory, if it won't be used in practice, there is no need for interoperability if it can't be built. >> Section 7.1 says "A client can add itself explicitly to the receiver set or >> add >> itself to the receiver set when requesting the TIPS view." It describes two >> methods for doing this, but neither indicates which request will remain open >> so >> that the client can receive push promises. > > LACHLAN: There is a single persistent connection between a client and a > server, which is the same one that the client uses to request the TIPS > view (and hence the one used to subscribe implicitly). For the explicit > case, the request to explicitly add the client to the receiver set MUST > be sent over the persistent connection. I think that you missed the point of the comment. Though HTTP uses connections, it doesn't use them in the way you describe. The atomic unit of HTTP is a request, and server push operates in relation to a request. When the server pushes, which request from the client will that push be associated with? >> This design is very complex. [...] > > LACHLAN: Section 5 details how metadata for a resource's TIPS view > (e.g., details about the updates graph, etc.) can be retrieved. Since > we are dealing with dynamic resources that are constantly updating, a > client may desire to determine how they are changing. Can you elaborate > why this principle would be hurtful? Resources can be used to model just about anything. Here, the TIPS view resource model is bound to a connection. Though possible, this is unwise from the perspective of any protocol that uses HTTP, because HTTP tries very hard to make the details of connections are made and maintained immaterial to its operation. Section 5 builds an additional layer on top of that abstraction. Your meta layer models details of your subscription service. This is fine in the abstract, but that doesn't necessarily make for a good standard. A standard exists in the furtherance of interoperability. Small standards are more likely to implemented successfully. More stuff means a bigger ask of implementations and how they manage and expose their internal state. By requiring that servers expose their entire graph in a way that can be queried this way, you force them to codify certain details, rather than - as core ALTO does it - letting servers do whatever they determine to be best for getting clients up to speed. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
