The major concerns I had are gone. Thanks. I don't think that I'll have time to check on the finer details though.
On Wed, Oct 11, 2023, at 13:15, [email protected] wrote: > Hi Martin and all, > > A new revision (-15) has been submitted to address the Httpdir last call > review. > > Highlights: > > - Persistent connection and related sections are removed. A short > discussion is added to the appendix explaining the reason. > - A new heartbeat request is introduced to check client liveness for a > TIPS view. > - <tips-view-uri> is now an absolute path to enable potential scoping > with subdomain. > - Specs for push-mode TIPS and related sections are removed, except a > short discussion left in the appendix. > > Please let us know if the proposed changes resolve the issues. Thanks! > > Best, > Kai > >> -----Original Messages----- >> From: [email protected] >> Send time:Thursday, 10/05/2023 16:25:23 >> To: "Martin Thomson" <[email protected]> >> Cc: [email protected], [email protected], >> [email protected], [email protected] >> Subject: Re: [alto] Httpdir last call review of >> draft-ietf-alto-new-transport-14 >> >> >> >> >> > -----Original Messages----- >> > From: "Martin Thomson" <[email protected]> >> > Send time:Thursday, 10/05/2023 11:26:32 >> > To: kaigao <[email protected]> >> > Cc: [email protected], [email protected], >> > [email protected], [email protected] >> > Subject: Re: Httpdir last call review of draft-ietf-alto-new-transport-14 >> > >> > On Thu, Oct 5, 2023, at 13:53, [email protected] wrote: >> > > We will really appreciate it if you can point us to any work that has a >> > > better >> > > design, as it looks like a generic problem. >> > >> > The namespacing issue is easy to address using the design I sketched out. >> > That's a pretty common pattern. >> > >> > The heartbeating mechanism you describe could work, though it could end up >> > being wasteful. >> > >> > There is an alternative here, which is to avoid server-side state and put >> > the necessary state into the URL you return to clients when "creating" a >> > view. >> > Then you don't need to rely on liveness checking so much. You can have >> > server >> > side caches for any essential state that carries between requests, but you >> > don't >> > rely on that state being present. Any state can be cleared as necessary >> > (on a >> > timer, say), without needing constant pings, because it can be recovered if >> > necessary from the URL. If you can get away with having no server-side >> > state at >> > all, this is even better, but I don't know how much these views represent >> > substantial investment in computation or state such that it might be >> > awkward to >> > transfer that with every request. >> >> Unfortunately this is not feasible in our case. The fundamental states >> include >> >> 1. resource of interest >> 2. parameters (e.g., filters) >> 3. data & updates of the interested resource based on the parameters >> 4. the current version of the client's data >> >> We already encode 4 in the URL but the first 3 (especially 3) are the most >> resource-consuming states. Unfortunately 3 can only be maintained by the >> server and depend on 1 & 2. >> >> In the ideal case, the client should release the resources when it >> terminates. >> However, in case of failure or DoS attack, the heartbeat mechanism is needed >> to identify resources that are no longer being used. >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
