Hello there, During my work on adding HTML5 audio/video to WebKit, I hit an issue with the design of the Media Kit and the way plugins are loaded. I'm not talking about media add-ons, these live only in the media_server and work fine. I'm talking about plugins, which are used for decoding and encoding audio and video files. We currently have a single one that uses ffmpeg to decode all formats we support. Unlike add-ons, the medi plugins are loaded in the application memory space. The current design is as follows: * The media_server monitors the plugins directories. When a file is added, it instanciates the plugin in order to identify wether it is a decoder, encoder, reader or writer. 4 lists for these 4 kind of plugins are managed by the media_server. * When an application wants to decode or encode a file, it gives the media_server a format information, and the media_server identifies and returns the matching plug-in, in the form of an entry_ref. * The application loads the plugin, instanciates it, and uses it for decoding (this is wrapped in Media Kit classes, BMediaFile and BMediaTrack). This is where things break for hybrid apps: the plugin returned is always for the primary architecture, and doesn't work on the secondary one. This design is similar to the way BeOS worked. The idea is that the media_server can cache the mapping of media formats to matching plugins, and thus find the right plugin without having to scan the disk, instanciate each of them, and ask it if the requested format is supported. There are several ways to change this, but I'm not sure which is best, so I'd like more opinions. 1) Move everything application side. Besides the monitoring and caching, media_server never uses the plug-ins. So this could be moved to the application side (in the Media Kit). Each app could do the caching of format>plugin, possibly with a lazy initialization as formats are requested. There could be a problem with all apps monitoring the plugins directories, but I'm not sure that's needed. It was important in the media_server to allow adding new formats without restarting the server, but restarting an app to get a new format (something that doesn't happen very often) sounds reasonable. Alternatively, the add-ons on disk could be re-scanned each time a request to find a plugin is made. I'll add that the current media_server code re-scans the plugin directories each time a request is made, to make sure that plugins stored in user directories are tried first, and system ones second. This doesn't seem to have an unacceptable performance impact. Ultimately the plug-in still has to be read from disk and instanciated in each application, so the cost of browsing the disk to locate it is not so high. 2) Keep things in the media server To keep the monitoring and caching shared between apps, we would have to keep things on app_server side. While monitoring the plugins for the secondary architecture is easily possible, there is no way to instanciate the add-ons to detect which kind they are (reader/decoder/writer/encoder). One way to achieve this would be to have an hybrid-compiled part of the server running just for this purpose (as a separate team). The server would delegate all requests comming from hybrid apps to that. What would you suggest? -- Adrien http://pulkomandy.tk