Display interface
At the circulation desk there is often a second screen next to the member of staff, facing the patron: a greeting, what has just been charged, when the next item is due back, whether any fees are outstanding.
This part describes how a program drives such a display – SBC-AP for short (SBC display protocol).
Who talks to whom#
The interface knows exactly two roles:
| Role | What it is | What it does |
|---|---|---|
| Controlling program | the library software | issues requests |
| Display | the program that drives the screen | carries them out and responds |
The controlling program asks, the display answers – never the other way round. Every request receives exactly one response. Unlike the circulation interface, however, the display does keep state: it knows which session is running and retains its data until that data is changed or the session ends.
The guiding principle#
The controlling program supplies data; the display words and designs.
The protocol therefore carries "2026-08-29" and not "Sat, 29 Aug 2026", let
alone "in 5 days" or "overdue". It carries a number of reservations, not the
sentence that is made from it.
This single rule decides everything else. It allows
- Multilingualism: the display words things in the patron's language without the library software knowing anything about it.
- Interchangeability: the same software drives displays from different manufacturers, and the same display obeys programs from different manufacturers.
- Different devices: a narrow strip above a till and a 55-inch screen receive the same data and make of it whatever suits them.
Why a standard of its own#
For patron displays there is nothing comparable to SIP2. What does exist concerns other layers: PJLink (external site) and DDC/CI switch screens on and off and select the input; SMIL describes image sequences for advertising. None of it says anything about what a library wants to tell its readers at the desk.
Hence this interface – small, open and described in a way that lets it grow.
The structure of this part#
- The message structure describes the frame: the connection, how a request is built, error codes, how data is written and the rules by which the protocol may be extended.
- The commands are the heart of it: four areas from the heartbeat to shutting down, plus the states of a display and the profiles against which conformance is measured.
- The field overview lists every field alphabetically – for looking things up while reading a log.
- Operation covers everything around the protocol: how a display is found, how the connection is secured, which personal data may appear on a screen standing in public, and what both sides undertake to do.
What is not laid down#
The standard describes the exchange of data – not the device and not the design. It says nothing about layout, typefaces, colours, imagery, transitions or advertising, and it does not prescribe which of the transmitted data a display actually shows. A display that shows nothing of a session but the greeting and the number of items on loan is just as conformant as one that shows every cover.
Nor does it say how the screen is driven technically: whether the display is a second window on the same computer, a small computer behind the screen or a television in the entrance area is left open.
Without a desk, too#
Not every screen belongs to a workplace. An entrance screen greets visitors and states today's opening hours; an exit screen says goodbye and reports when the security gate is triggered.
This part covers both in full, without a session ever beginning:
| For what | Command |
|---|---|
| name of the library, opening hours, closures, events | venue.set |
| greeting, a sequence of images | idle.slides |
| notices such as "Today we close at 4 pm" | message.show |
| a single item with its cover, e.g. on a gate alarm | media.show |
Such a display meets the "notice display" profile and need know nothing of the
session area.