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