I'm not sure if my email did reach chromium-dev, but John's reply
contains it as quoted text. In any case, repeating here:

Hello, we are a small group of Googlers who'd like to volunteer our
20%
time to work on plugin management, and eventually plugin update in
Chromium.
At first we'd like to start working only on management. We'd
appreciate if
you could review our proposal and provide feedback.

Chromium plugin update proposal
http://docs.google.com/View?id=acphg8jwwrqk_133d2q9k5d3

Chromium Plugin Manager Proposal  <-- We think we can start working on
this first
http://docs.google.com/View?id=acphg8jwwrqk_131fknzfnd7


Thanks,
Panayiotis.


On Dec 7, 11:28 am, John Abd-El-Malek <j...@chromium.org> wrote:
> This is much needed, thanks for working on it :)
>
> Some notes:
> -Putting it in a url, but not having a menu item, removes much of the
> benefit since only a tiny percentage would be able to use it.
> -Checking that each plugin is up to date should be automatic and enabled for
> all users, just like our plugin installer is automatic.  I don't see the
> benefit of having that functionality be listed as a "plugin", especially
> since that can't be completely done inside an NPAPI plugin.
>
> Can you put this information in a mini design doc somewhere online?  Also
> things like exactly how you propose to implement this, and the future
> features (i.e. disabling plugins that have big security holes, asking the
> user to update etc...)
>
>
>
> On Mon, Dec 7, 2009 at 11:08 AM, Panayiotis <panayio...@google.com> wrote:
> > Hello, we are a small group of Googlers who'd like to volunteer our 20%
> > time to work on plugin management, and eventually plugin update in Chromium.
> > At first we'd like to start working only on management. We'd appreciate if
> > you could review our proposal and provide feedback.
>
> > Thanks,
> > Panayiotis, Noe, Nav.
>
> > *Plugin Manager UI Proposal *
>
> > *Purpose*: UI for managing (enabling/disabling) plugins in Chromium.
>
> > *Background*: There's a lot of reasons why this would be desirable, most
> > are reported inhttp://code.google.com/p/chromium/issues/detail?id=736,
> > major ones include security and performance
>
> > *Suggested solution: *
>
> > The User Interface could look a lot like chrome://extensions. We could use
> > for example *chrome://plugins*/ for its url. A user would have to type the
> > url to get to it, we would not link to it from any menu. Very similar to
> > chrome://extensions, it would be a table of all plugins, with ability to
> > enable/disable plugins. A mockup is attached.
>
> > All plugins, plugin name, plugin description, plugin version (see below)
> > and full filename of the plugin on the filesystem would be listed. Disabled
> > plugins look like disabled extensions and have an "enable" link, enabled
> > plugins have a "disable" link.
>
> > *Non-goals:*
>
> >    - We don't want to be able to enable/disable plugins per-site/ per-tab
> >    at this point.
> >    - There won't be any notification to the user that a plugin was
> >    attempted to be used -- this can be hard to detect because many pages 
> > use JS
> >    to see if the plugin is installed and show different content if it's not.
> >    It's not impossible, but we think we shouldn't aim for this in the first
> >    iteration.
>
> > *Alternative ideas we considered:*
>
> >    - Modify about:plugins for this purpose. That page is a simple
> >    javascript page that iterates over navigator.plugins. Similar to other
> >    about: pages it doesn't have access to chrome internals. We feel
> >    chrome://plugins follows the model of chrome://extensions better, in that
> >    this page cannot be inspected and allows the user to modify state of the
> >    browser.
> >    - Have a popup window similar to Firefox's Add-on manager. We feel
> >    mimicing chrome://extensions is going to be more consistent, besides, 
> > having
> >    it be a url allows you to load it in a tab.
> >    - Add the plugins to chrome://extensions  -- we can do that too, we'll
> >    let Chromium devs chime in on what's the preferred option here.
>
> > *Implementation details:*
>
> >    - Modify mostly PluginService (chrome/browser/plugin_service.cc)
> >    - Will store state in the sqlite database, per user.
> >    - A plugin is identified by its path in the filesystem. Different paths
> >    are considered different plugins.
> >    - Once a plugin is disabled, all subsequent calls to create a plugin
> >    instance will fail. Similarly for enabling. Pages that have the plugin
> >    already loaded should still work.

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev

Reply via email to