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 wrote:
> Perhaps something like PluginList::AddExtraPluginPath can be added which
> takes the parameters you mentioned. This should be easy to do, I'
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
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
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, registerin
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 wrote:
> In that case, registering with a WebPluginInfo/function pointers would be
> better than keeping around PluginVersionInfo. Real data structures F
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 wrote:
> My immediate usage case is for the chromium embedded framework (CEF):
> http://code
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 bro
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 dynam
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,
On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt 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::R
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
On Tue, Jan 20, 2009 at 1:48 PM, John Abd-El-Malek 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. ReadWebPlugi
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 f
13 matches
Mail list logo
