Open Source Projects Europe

// Content Directory service

//

// The actual work is done by separate plugins (CDPlugin interface),

// depending of where the data comes from (streaming service, e.g,

// Tidal, Qobuz, or local file store - uprcl). There is currently a

// single implementation of CDPlugin (PlgWithSlave) for which most of

// the differentiated work is done by a Python subprocess specific to

// the backend.

//

// The CDPluginServices interface provides some service callbacks to

// the implementations.

//

// The class is responsible for generating the root directory,

// according to what services are enabled. For deeper directories, the

// dispatch to the right service is performed according to the first

// element in the object ID (e.g. $qobuz$).

//

// Accordingly, the media access also depends on the type of backend,

// and some media URIs are also formed in order to be dispatchable

// (e.g. http://xxx/qobuz/...). Some also point directly to a server

// implemented by the plugin. Depending on the service, either

// redirection or proxying is used to supply the data stream.

//

// We also have a special operation mode where the browsing is done by

// the CP and we are only used for accessing the streams (see

// constructor comment).

    // Constructor.

    // 

    // Enabled==false: means that no content directory service is

    // actually needed. No service will be enabled, but we perform

    // some initializations. This is used in conjunction with

    // OHCredentials. The Control Point (typ. Kazoo) does the

    // browsing, and sends tidal://xx or qobuz://xx URIs to

    // OHPlaylist. The URI contain the service trackid, and are

    // translated by OHPlaylist/OHCredentials into the form which is

    // generated when this class does the browsing. The data access is

    // then performed as if the URIs had been generated by us.