PluginList only needs WebPluginInfo structs, as its purpose is just to
figure out which plugin can handle a mimetype. The trick we do is that we
denote internal plugins using "special" filenames. For example, look at the
internal plugin (kDefaultPluginLibraryNameLook).
The function pointers are stored in the platform specific plugin lib file.
In plugin_lib_win.cc, it's g_internal_plugins. You'll have to convert this
to a std::vector, and then you can add a static method to PluginLib to add
items to it.
On Tue, Jan 20, 2009 at 1:07 PM, Marshall Greenblatt <magreenbl...@gmail.com
> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
