W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] Persistent SharedWorkers

From: Drew Wilson <atwilson@google.com>
Date: Fri, 6 Mar 2009 15:46:52 -0800
Message-ID: <f965ae410903061546v575d6563g670b6d15e8dd18ea@mail.gmail.com>
Agreed, there is definitely some overlap between extensions and persistent
workers. I've been trying to sort out exactly how similar they are (Note:
I'm mostly familiar with Firefox extensions/plugins, and mostly as an
end-user - some of my assumptions may be incorrect):

* Install - they both have some sort of permissions/installation model where
the user is prompted to grant permission to do whatever the module wants to
do. This may just be a problem of perception, but I've always viewed
plugins/extensions as having a much higher cognitive burden than persistent
workers - if a website wants to install a plugin or extension, that
plugin/extension can potentially do lots of stuff: view/modify page content,
break cross-domain boundaries, render content, etc. A PersistentWorker can't
do anything that the web page itself can't already do - it just continues to
do it after the last window for that domain has been closed - so saddling
persistent workers with the full permissions model of extensions/plugins
seems too heavyweight, and a drag on user adoption.

* Updates - extensions are installed by the user, and on some platforms are
never updated except by explicit user action. Extensions have the ability to
say "I'm only compatible with version X of the browser" but don't really
have a way to say "I'm only compatible with the 2/23/2009 build of Website
X". This seems to run counter to the paradigm that web applications have
full control over their own source code. That said, undoubtedly there are
ways for web applications to work around these restrictions (for example, by
prompting the user to update their extension if it's determined to be
out-of-date).

* Compatibility - as you note, there doesn't seem to be much cross-platform
consensus on extension APIs. So, I suppose one view is that I'm defining a
tiny subset of extension behavior, codifying it in a cross-platform manner,
and calling it PersistentWorkers. But you could say the same thing for
Workers in general :)

I think part of my reluctance to tie this too closely to extensions/plugins
is that I quail at the thought of trying to define cross-browser extension
behavior. But I do agree that sharing some of the install/management UI
probably makes sense.

-atw

On Fri, Mar 6, 2009 at 2:11 PM, Martin Atkins <mart at degeneration.co.uk>wrote:

> Drew Wilson wrote:
>
>>
>> - Permissions:
>> Installing a persistent worker is essentially giving a web application a
>> near-permanent footprint on your PC - we need explicit permission from the
>> user, and we need some mechanism in the user agent to revoke this
>> permission. There are a number of examples of similar permission-granting
>> user flows (ActiveX installation, plugin install, gears) which we could use
>> as a model for our "grant/revoke permission" UI.
>>
>>
> I think it'd be great if these things could behave in almost all respects
> like an extension or plugin that's been installed by other means. For
> Firefox it'd show up in the "Add-ons" dialog, for example.
>
> As a user, I don't really want to care which mechanism a site is using to
> install its extension, so having them all listed together regardless of
> whether they're NSAPI plugins, Gecko extensions or persistant workers would
> be nice.
>
> In some ways, it seems like effectively what you're trying to achieve is a
> standardized approach to Gecko extensions or Browser Helper Objects or
> whatever, hopefully also associated with some kind of permissions model that
> constrain what the extension is allowed to do in the browser to a greater
> extent than allowed by traditional extensions.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090306/61ad65df/attachment.htm>
Received on Friday, 6 March 2009 15:46:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT