[chromium-dev] Re: Thoughts on the default plugin
The patch is now available for review: http://codereview.chromium.org/19625 Thanks, Marshall 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.comwrote: 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on the default plugin
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? That sounds like a more streamlined approach. I like it :-). --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on the default plugin
I like pulling the structures out of public view. Altering ReadWebPlugInfo sounds reasonable, but it's called by code outside plugin_lib, so callers have to deal with two things coming back (a WebPluginInfo and a pointer set). If you can do it cleanly, it sounds good. Avi 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on the default plugin
Where would this be used? On Tue, Jan 20, 2009 at 11:24 AM, 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.orgwrote: 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on the default plugin
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.orgwrote: 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on the default plugin
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.orgwrote: 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on the default plugin
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.orgwrote: 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.comwrote: 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on the default plugin
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.comwrote:
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
-~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on the default plugin
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.orgwrote:
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.orgwrote:
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.comwrote:
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
