Message-ID: <1488839905.2134.7.camel@mmci.uni-saarland.de>
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>, Bitcoin Protocol
	Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Mon, 06 Mar 2017 17:38:25 -0500
In-Reply-To: <1488839459.2134.5.camel@mmci.uni-saarland.de>
References: <201703040827.33798.luke@dashjr.org>
	<201703060709.40311.luke@dashjr.org>
	<1488837256.2134.1.camel@mmci.uni-saarland.de>
	<201703062214.47660.luke@dashjr.org>
	<1488839459.2134.5.camel@mmci.uni-saarland.de>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Currency/exchange rate information API
Precedence: list

On Mon, 2017-03-06 at 17:30 -0500, Tim Ruffing via bitcoin-dev wrote:
> 
> That works but a standardized way of indicating that piece of
> information to the client is useful. Then the client can display a
> "connection status" to the user, e.g., an "possible out-of-date"
> warning like the warning sign in the Qt GUI when Bitcoin Core is
> catching up the network.

Wait, forget this reply, I mixed up the two issues of keepalive and
definition of low, high etc... -.-

1. Keepalive for longpolling:
As I said, this can be useful for an out-of-date warning. I don't know
if this is better solved with TCP keepalive or on the higher layer.

2. Definition of low, high:
My feeling is that there is nothing wrong with providing exact
definitions in the BIP, i.e.., giving up the flexibility does not too
hurt much. However all of this is a minor issue after all.

Tim