__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> '
|
|