The modularity of BAPS3 allows for discrete servers to collaborate together to implement services, and for clients to communicate with any such service that speaks one of the BAPS3 APIs. However, services and their constituent servers may implement a variety of subsets of the full BAPS3 feature set as specified, and may even implement extensions or customisations of standardised behaviour.
To allow a BAPS3 server to report a fine-grained set of capabilities it implements, either directly or via communication with other servers, BAPS3 supports the concept of features: distinct named collections of Internal API requests, states, and responses, as well as External API resources. In addition, every server should implement the core feature, comprising basic protocol functionality such as initial responses and server control.
In the internal API, the FEATURES core initial response provides the
names of all features, core excepted, that the server directly or
indirectly implements. In turn, each feature enables various Internal
API requests and responses, or new functionality on existing requests
and responses.
This section is to be written at a later date.
FEATURES is not a difficult system to implement. Baseline services
such as players need only provide a stock response to upstream
clients upon connection. Services that communicate downstream need
only parse the FEATURES command, optionally check for dependencies
and conflicts, append their own features, and emit the result.
The FEATURES system allows the Internal API to be used in multiple
different contexts. A player implements the same API as a playlist,
and the composition of both into a player-playlist also implements
the same API.
Due to the ability to pass-through unknown requests and responses,
and the ability to take the union of FEATURES responses, two
services can be composed to produce a new service implementing the
union of both services' features.
For example, a playlist service can attach to a player service to provide playlist functionality on top of that of the player, so long as the player provides the necessary features for loading and playing files. The result, as far as any clients of the playlist are concerned, is a single service that provides playlist and playback functionality.
Suppose the player, in addition to the required features specified
in this document, supplies a Volume feature allowing the player’s
volume to be controlled. Without any special handling by the
playlist, the composed service exposes the Volume feature and
passes through any volume changes to the player.
When an upstream service connects to a downstream service, it can
check the downstream FEATURES response for any features on which
it depends.
For example, the Playlist feature depends on the downstream service
having the FileLoad feature.
In addition, the upstream service can check the downstream FEATURES
to ensure that any functionality it provides does not conflict with
functionality already present in the downstream.
FEATURES provides clients with flexibility to target multiple
different combinations of BAPS3 services, if they desire, by adapting
their user interfaces to reflect the FEATURES declared.
For example, a client may be attached to a player, and display
controls for loading a single file, as well as seeking, playing,
stopping and ejecting. The same client may also be attached to a
playlist-player, at which point it adds in a playlist interface.
If the playlist-player supports the hypothetical Volume feature,
it may then also add a volume control.