The ICT consumer market is weary of Telemetry...I bought a Chinese tablet for US$4 but if you go to the BIOS which is in Chinese it has one of the most GPS receiver systems in the World
On Thursday, October 5, 2023 at 11:26:15 AM GMT+3, <kaigao@xxxxxxxxxx> wrote:
> -----Original Messages-----
> From: "Martin Thomson" <mt@xxxxxxxxxxxxxx>
> Send time:Thursday, 10/05/2023 11:26:32
> To: kaigao <kaigao@xxxxxxxxxx>
> Cc: ietf-http-wg@xxxxxx, alto@xxxxxxxx, draft-ietf-alto-new-transport.all@xxxxxxxx, last-call@xxxxxxxx
> Subject: Re: Httpdir last call review of draft-ietf-alto-new-transport-14
>
> On Thu, Oct 5, 2023, at 13:53, kaigao@xxxxxxxxxx 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
