Re: [Trans] Long Poll

Evgeny <xramtsov@gmail.com> Fri, 22 March 2019 17:24 UTC

Date: Fri, 22 Mar 2019 20:24:30 +0300
From: Evgeny <xramtsov@gmail.com>
To: trans@ietf.org
Message-Id: <1553275470.1281.2@smtp.gmail.com>
In-Reply-To: <20190322164812.jajis3kx6qbxn25f@work>
References: <1553165248.1179.0@smtp.gmail.com> <CALzYgEfEgO2R_SwsAE-UtqV0rPAX9trcREt2jCTw_i1OHsXQFg@mail.gmail.com> <1553186500.1179.1@smtp.gmail.com> <1553195698.1179.2@smtp.gmail.com> <20190322164812.jajis3kx6qbxn25f@work>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/tnR_NjcuZPUyq0Vz8GO1RDB2zUk>
Subject: Re: [Trans] Long Poll
Precedence: list

On Fri, Mar 22, 2019 at 7:48 PM, Rasmus Dahlberg 
<rasmus.dahlberg@kau.se> wrote:
> You could fetch the latest STH periodically based on how often a log 
> can produce
> it: see MMD and STH frequency in Section 4.1.  For example, checking 
> once per
> hour makes sense if a log's MMD is 24 hours and its STH frequency is 
> 24.  If you
> are looking to fetch STHs today, i.e., from a log that is not CT/bis 
> compliant,
> you could learn how often STHs are normally produced by some initial 
> polling
> tests. Another option is to simply pick an interval that suits your 
> needs,
> preferably without being to aggressive based on how often STHs are 
> produced.

Well, yes, I understand all this. Even if long polling is suboptimal in 
some sceanrios, what stops the authors from introducing long-polling 
API request for STH, it can be even optional. Because in my use case 
(that's a long story) I find long polling a better fit.