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):<br>
<br>* 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.<br>
<br>* 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).<br>
<br>* 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 :)<br>
<br>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.<br>
<br>-atw<br><br><div class="gmail_quote">On Fri, Mar 6, 2009 at 2:11 PM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Drew Wilson wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
- Permissions:<br>
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.<br>

<br>
</blockquote>
<br></div>
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.<br>

<br>
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.<br>

<br>
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.<br>

<br>
</blockquote></div><br>