I agree, registering with a WebPluginInfo and function pointers would be the ideal solution :-).
On Tue, Jan 20, 2009 at 2:57 PM, Avi Drissman <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
