A chart reads a series with one history call and one live subscription

Table of Contents

1. Summary

A client plots a series with two separate calls. A live subscription delivers each new tick, and the history call returns every tick of a span in one reply. The client subscribes first, calls second, and merges the two itself by coordinate and time. The server never merges history with the live stream for a client, because that merge would put a read of the store on the live path.

2. Detail

2.1. The claim

The merge belongs to the client. The server cannot know which ticks a client already holds from the stream. A merge on the server would also make the live path wait for the store, and the pipeline forbids that: a chart reads the newest value at once, whatever the database does. So the two reads stay apart, and each one can fail without the other.

a_chart_reads_a_series_in_two_calls.png

Figure 1: A chart opens, stays open, reconnects and scrolls back.

Source: a_chart_reads_a_series_in_two_calls.puml. Regenerate with plantuml -tpng doc/knowledge/architecture/a_chart_reads_a_series_in_two_calls.puml.

2.2. The order of the two calls

The client subscribes before it asks for the history, and it buffers each live tick until the reply arrives. A tick that arrives between the two calls is then in the buffer and not lost. The live subject names the series in its tokens, so the broker sends only the ticks of that series. The lane conflates that stream, so it can skip ticks that the history holds. A chart buckets its points, so the skipped ticks change nothing that it shows.

2.3. The merge

The key of a tick is its coordinate and its time. A tick is immutable, so two ticks with one key are the same tick, and the client keeps one of a pair.

  1. Put the ticks of the history reply in the series.
  2. Add each buffered live tick that the series does not hold.
  3. Add each later live tick as it arrives.

The overlap between the reply and the buffer is harmless. It is the safe side of the race between the two calls.

2.4. What a chart does

  • On open. Subscribe, then call for the span the chart shows, then merge.
  • On reconnect. Subscribe again, then call with from set to the newest tick the client holds. The reply holds the missed span.
  • On scroll to an older span. Call with to set to the oldest tick the client holds. The reply holds the older span only.

A gap that holds more ticks than the ceiling is refused. The client then calls for the gap in several spans, one after the other, and merges each reply.

No call repeats a span that the client holds. Each call returns everything its span holds, so a chart never loops on pages.

2.5. Where the other reads stand

A tick is not an observation, so the list of observations never returns one. See A quote series is keyed by item, provider and party. The value of a series at a date is a question of valuation, and the as-of reads answer it. See Snapshots and cuts. A chart needs neither: it needs the history of ticks, and the live stream.

3. See also

Emacs 29.3 (Org mode 9.6.15)