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