I was just reminded of this thread. I'm not sure if it was premeditated, but having the mime-types be a function (NP_GetMIMEDescription) is actually important for a specific Linux use-case. nspluginwrapper is a single plugin that proxies access to other plugins (for example, 64bit -> 32bit). It doesn't know at build time which plugins it will be proxying for. At runtime, it's initialization will walk the directories specific in the npw configuration, and look for suitable plugins to proxy.
You should be careful with caching metadata here also, since nspluginwrapper's library.so could be the same, but it could now be proxying more / different plugins. On Wed, Jan 28, 2009 at 8:50 AM, Darin Fisher <[email protected]> wrote: > Hmm, yeah... if it is easy to do so without a lot of code, that'd be great. > -Darin > > On Tue, Jan 27, 2009 at 11:36 PM, John Abd-El-Malek <[email protected]> > wrote: >> >> One of my goals with the out of process worker code is it to make it >> easier to have many different types of child processes. Perhaps it makes >> sense to have the linux port do this stuff in a child process once that code >> is ready. >> >> On Tue, Jan 27, 2009 at 10:49 PM, Darin Fisher <[email protected]> wrote: >>> >>> Wow. It sucks that we'll need to load plugins in the main browser >>> process. That gives plugins a nice opportunity to hose the browser. Oh >>> well :-( If we really wanted to, I suppose we could have a plugin scanner >>> process, but that seems unfortunately heavyweight. >>> -Darin >>> >>> >>> On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin <[email protected]> wrote: >>>> >>>> I'd been sending this sort of stuff to Dean and John but maybe other >>>> people will find it interesting. >>>> >>>> Plugin loading works in two phases: >>>> - at startup, we scan the plugin directories for metadata, like plugin >>>> names and which mime-types they apply to; >>>> - at runtime, when we're asked for a specific plugin by mime type, we >>>> open the appropriate library and have at it. >>>> >>>> On Windows and Mac, the startup step queries file metadata (version >>>> info on Windows, plists on Mac). >>>> On Linux, that step must dlopen() the plugin and poke a function in >>>> it. This means if a plugin ends up getting used we open it twice, >>>> which is especially brutal because Flash can take multiple seconds to >>>> open for me (complicated story, Adobe is working on it). >>>> >>>> It appears that Mozilla (maybe for similar reasons) caches this info >>>> across browser runs and relies on the file mtime to see when its cache >>>> has expired, much to some users' dismay: >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=125469 >>>> Or at least they did in 2002. ;) >>>> >>>> For now (for test_shell) I think I'll just pay the double-load cost. >>>> The alternative is leaving plugins open, which I think wastes memory >>>> and hurts load time. At some point we'll have to look at performance >>>> and decide about the cache thing. >>>> >>>> PS: Do we scan for plugins on a background thread in the normal >>>> browser startup? If so, how do we prevent races between that scan and >>>> someone's home page requesting a plugin? >>>> >>>> >>> >>> >>> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
