Package elisa :: Package core :: Module media_manager
[hide private]
[frames] | no frames]

Module media_manager

source code

Classes [hide private]
  MediaProviderNotFound
  MediaManager
Provides access to files through the use of MediaProvider components which allows to handle different file I/O protocols using URIs.
Variables [hide private]
  __maintainer__ = 'Philippe Normand <philippe@fluendo.com>'
MediaManager & MediaProvider notes and ideas - The MediaManager can ask the MediaProvider component if a URI is cacheable.
  DB_CONNECTIONS = {}
Variables Details [hide private]

__maintainer__


MediaManager & MediaProvider notes and ideas


- The MediaManager can ask the MediaProvider component if a URI is cacheable.
  The MediaManager should have a totally abstract view on the type of data it
  is managing, the MediaProvider implements all data specific cases.

- When a media access is requested through the MediaManager, it is up to the
  MediaProvider to implement this operation as a singleton or simultaneous
  data access. i.e : you could open two files on two samba servers at the
  same time.

- That media request needs to provide non-blocking and blocking calls.
  Blocking I/O operations called from the main thread should raise an
  exception, in an effort to keep the entire program to block (the
  intention is to have Elisa as plugin-weakness safe as possible)

- The MediaProviders should have functions to provide meta data to the
  MediaManager. The data structure of the meta data should be
  predefined. **NOTE**: This isn't specific to MediaProviders,
  IMHO. Metadata retrieval should be implemented using GStreamer
  and/or a third-party library (like TagLib). MediaProviders provide
  URI data support, but they shouldn't be aware of the kind of
  multimedia files they provide access to. This is the job of the
  underlying multimedia framework. -- Philippe
  - We do it now with the usage of a dictionary containing metadata

- The MediaManager is portable by design. The MediaProviders can be
  system-dependent or requiring external applications running.

- The MediaManager's caching system could have parallel lists of contents
  to cache depending on the resource type. MediaProvider could provide
  a way for the MediaManager to know if the resource is likely to take
  long to retrieve or not. For example, if there is only one to-cache list,
  if the first 10 elements are HTTP resources and the next are from the
  local filesystem, the local filesystem resources could be processed in
  parralel to provide faster access to them. **NOTE**: How do you define
  "long to retrieve"? For me every task should be long by
  definition. -- Philippe
  **NOTE2**: then no parralelism. Although you can be pretty sure a local
  disk access will really be faster than a HTTP request, so it could come
  handy - although it's some kind of specials case - cause it might give the
  user a better responsivity.

- The caching system should be priority-list oriented. Priorities should
  be assigned to Medias to cache, and a request to MediaManager cached
  media should be able to interrupt current caching and process the
  request first.

- The MediaManager could count accesses to data. Those statistics could be
  considered as metadata, and could be retrieved by Components.

- The Components could add metadata to the Medias (like tags).
  However it will be needed first to ensure that the data given by the
  Component cannot cause a database corruption. **NOTE**: This
  metadata would be stored both on db and in files? -- Philippe
  **NOTE2**: DB for sure, and maybe in files if the MediaProvider
  supports it ?

- It should be possible to place a restriction on the Cache database
  file size.  That would be necessary in the case of Elisa running on
  a system more aimed at retrieving data from networks, that has a
  low-capacity hard drive. **NOTE**: What would we do when db file
  size exceeds the limit? drop some db records? never add anything
  more in the db? :) The box we have in mind will have a CF card, we
  found out that even with huge media libraries the db size doesn't
  exceeds 20mb. This also depends on how the db is designed. -- Philippe

  **NOTE2**: This is in a way related to fault-tolerancy (CF card or not).
  The behaviour should be IMHO to stop caching -- Colin

- The MediaManager should have different monitor location list
  depending on the time the user wants it to check for updates of
  these locations (one time, 5 minutes, 30min, hourly, daily, ...)

  There should also be an unmonitored location list so that the user can
  explicitly tell the MediaManager not to do caching on certain locations.

  The MediaManager will also ask the MediaProvider components if it can do
  monitoring on the medias that are relevant to a certain MediaProvider
  (like INotify for Local FS support).

  The MediaProviders can indeed add locations to monitor (HAL plugin
  for example). **NOTE**: I don't understand that example. The HAL
  plugin doesn't provide a media_provider, does it? -- Philippe
  **NOTE2** I was thinking about the case MediaProvider get signaled
  by the HAL plugin (which is not a MP) that a new location is available
  -- Colin

- MediaProviders should be able to provide source elements for
  GStreamer. This can become handy for URIs not supported (yet) by
  GStreamer but supported by MediaProviders who have access to the
  data (example: DAAP uris)

Value:
'Philippe Normand <philippe@fluendo.com>'