PluginList maintains a vector of WebPluginInfo structs. As-is, that won't
let us store the function pointers. Should we:
1. Add the function pointers as members of the WebPluginInfo struct in
webplugin.h
2. Change PluginList::plugins_ to a vector of structs like the following
that would only be used internal to PluginList:
struct PluginListInfo {
WebPluginInfo plugin_info;
NP_GetEntryPointsFunc np_getentrypoints;
NP_InitializeFunc np_initialize;
NP_ShutdownFunc np_shutdown;
};
3. Same as 2, but maintain these structures in a vector separate from
PluginList::plugins_ and only use for the dynamically registered internal
plugins.
On Tue, Jan 20, 2009 at 3:27 PM, John Abd-El-Malek <j...@chromium.org> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
