rhyslbw
commented
3 years ago Similarly, it would also be convenient to have the client automatically re-acquire the most recent point (i.e. the tip) if no point was provided initially. Note that, this is also the behavior of the server at the moment which does not require client to explictely acquire.
Ah yes, I agree. I can now see a flaw with the logic since providing a point is optional:
... but the acquire message is always sent:
Describe your idea, in simple words.
With the Local State Query protocol, queries are run against a specific point that has to be acquired upfront. Yet, acquired points can "expired" and become too old. It should be possible to re-acquire new points on demand.
Similarly, it would also be convenient to have the client automatically re-acquire the most recent point (i.e. the tip) if no point was provided initially. Note that, this is also the behavior of the server at the moment which does not require client to explictely acquire. Clients are free to send queries immediately, in which case they are executed against the latest tip. So all-in-all, implementing this could be as simple as avoiding the initial
Acquirewhen creating the state query client.Why is it a good idea?
Right now, the only work-around for an app would be to re-create a new client with a more recent point. That is quite unpractical.
Are you willing to work on it yourself?
Maybe.