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 -~----------~----~----~----~------~----~------~--~---
