Skip to content
Snippets Groups Projects
  • Matthew Jordan's avatar
    3ea0d383
    media cache: Add a core API and facade for a backend agnostic media cache · 3ea0d383
    Matthew Jordan authored
    This patch adds a new API to the Asterisk core that acts as a media
    cache. The core API itself is mostly a thin wrapper around some bucket
    API provided implementation that itself acts as the mechanism of
    retrieval for media. The media cache API in the core provides the
    following:
     * A very thin in-memory cache of the active bucket_file items. Unlike a
       more traditional cache, it provides no expiration mechanisms. Most
       queries that hit the in-memory cache will also call into the bucket
       implementations as well. The bucket implementations are responsible
       for determining whether or not the active record is active and valid.
       This makes sense for the most likely implementation of a media cache
       backend, i.e., HTTP. The HTTP layer itself is the actual arbiter of
       whether or not a record is truly active; as such, the in-memory cache
       in the core has to defer to it.
     * The ability to create new items in the media cache from local
       resources. This allows for re-creation of items in the cache on
       restart.
     * Synchronization of items in the media cache to the AstDB. This
       also includes various pieces of important metadata.
    
    The API provides sufficient access that higher level APIs, such as the
    file or app APIs, do not have to worry about the semantics of the bucket
    APIs when needing to playback a resource.
    
    In addition, this patch provides unit tests for the media cache API. The
    unit tests use a fake bucket backend to verify correctness.
    
    Change-Id: I11227abbf14d8929eeb140ddd101dd5c3820391e
    3ea0d383
    History
    media cache: Add a core API and facade for a backend agnostic media cache
    Matthew Jordan authored
    This patch adds a new API to the Asterisk core that acts as a media
    cache. The core API itself is mostly a thin wrapper around some bucket
    API provided implementation that itself acts as the mechanism of
    retrieval for media. The media cache API in the core provides the
    following:
     * A very thin in-memory cache of the active bucket_file items. Unlike a
       more traditional cache, it provides no expiration mechanisms. Most
       queries that hit the in-memory cache will also call into the bucket
       implementations as well. The bucket implementations are responsible
       for determining whether or not the active record is active and valid.
       This makes sense for the most likely implementation of a media cache
       backend, i.e., HTTP. The HTTP layer itself is the actual arbiter of
       whether or not a record is truly active; as such, the in-memory cache
       in the core has to defer to it.
     * The ability to create new items in the media cache from local
       resources. This allows for re-creation of items in the cache on
       restart.
     * Synchronization of items in the media cache to the AstDB. This
       also includes various pieces of important metadata.
    
    The API provides sufficient access that higher level APIs, such as the
    file or app APIs, do not have to worry about the semantics of the bucket
    APIs when needing to playback a resource.
    
    In addition, this patch provides unit tests for the media cache API. The
    unit tests use a fake bucket backend to verify correctness.
    
    Change-Id: I11227abbf14d8929eeb140ddd101dd5c3820391e