In that case, registering with a WebPluginInfo/function pointers would be better than keeping around PluginVersionInfo. Real data structures FTW.
Avi On Tue, Jan 20, 2009 at 2:51 PM, Marshall Greenblatt <[email protected] > wrote: > My immediate usage case is for the chromium embedded framework (CEF): > http://code.google.com/p/chromiumembedded/ > > CEF supports plugins that are an integrated part of the container > application. For instance, consider a medical viewing application where the > complete user interface is an embedded browser window. An internal plugin > is embedded in the browser window for viewing medical scan images. The > plugin depends on the medical viewing application (cannot function > independently), and so we compile both the viewing application and the > plugin into a single executable. > > Currently, CEF must duplicate the entire webkit\glue\plugins directory in > order to make the minor changes necessary to support this capability. If we > could dynamically register internal plugins via PluginLib then we could > eliminate the code duplication. > > I imagine dynamically registering internal plugins (as part of an > extension, for instance) might also be a useful capability once the chromium > extension framework is in place. > > > > On Tue, Jan 20, 2009 at 2:29 PM, Avi Drissman <[email protected]> wrote: > >> I'm trying to figure out a way to get away from PluginVersionInfo as it's >> very Win32-centric. >> >> BTW, what's the scenario that you have in mind that dynamic registration >> would help with? If we're making changes here, we should take your usage >> needs into account. >> >> Avi >> >> >> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt < >> [email protected]> wrote: >> >>> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt < >>> [email protected]> wrote: >>> >>>> It would also be nice if we had a public method for registering internal >>>> plugins dynamically, instead of having to modify the g_internal_plugins >>>> array in plugin_lib.cc. >>>> >>>> For instance (based on the current code): >>>> >>>> PluginLib::RegisterInternalPlugin(PluginVersionInfo version_info, >>>> NP_GetEntryPointsFunc >>>> np_getentrypoints, >>>> NP_InitializeFunc >>>> np_initialize, >>>> NP_ShutdownFunc >>>> np_shutdown); >>>> >>>> This would be functionally equivalent to adding an entry to the existing >>>> g_internal_plugins array, but would be run-time accessible from elsewhere >>>> in >>>> the code base. >>>> >>>> On Tue, Jan 20, 2009 at 1:48 PM, John Abd-El-Malek >>>> <[email protected]>wrote: >>>> >>>>> It seems that the only reason this code is needed is to get the >>>>> function pointers for the internal plugin. Perhaps the PluginVersionInfo >>>>> & >>>>> InternalPluginInfo stuff could be taken out of the platform independent >>>>> code. ReadWebPluginInfo can be modified to return both the WebPluginInfo >>>>> & >>>>> the three function pointers (if it's an internal plugin). What do you >>>>> think? >>>>> >>>>> >>>>> On Tue, Jan 20, 2009 at 9:33 AM, Avi Drissman <[email protected]> wrote: >>>>> >>>>>> I'm looking at InternalPluginInfo in plugin_lib.h. Its first component >>>>>> is a PluginVersionInfo, which is basically the Win32 version of the NPAPI >>>>>> data. Right now my plugin info parsing code pulls info from either a >>>>>> plist >>>>>> (via CFBundle) or resources, and neither is easy to reuse to parse a set >>>>>> of >>>>>> strings. What format does Linux have? Could we reuse the code? >>>>>> >>>>>> Avi >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
