Perhaps something like PluginList::AddExtraPluginPath can be added which takes the parameters you mentioned. This should be easy to do, I'd be happy to review it if you send me a patch :)
On Tue, Jan 20, 2009 at 12:00 PM, Marshall Greenblatt < magreenbl...@gmail.com> wrote: > 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 <a...@chromium.org> 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 < >> magreenbl...@gmail.com> 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 <a...@chromium.org> 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 < >>>> magreenbl...@gmail.com> wrote: >>>> >>>>> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt < >>>>> magreenbl...@gmail.com> 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 >>>>>> <j...@chromium.org>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 <a...@google.com>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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
