People communicate URLs effectively because there’s a clear link between “things” and “places” that exists in the real world and is fairly easy to transpose.

What you’re proposing is far too subtle and mentally-intensive for the public to ever master. The idea that an average person will be able to atomically catalog individual software functions and manage them by location is totally ludicrous.

And the Web is not on a push model AT ALL. Some applications of HTTP might be considered “pseudo-push”, at most, but the whole request / response model is totally pull-based. So I’m not sure exactly why a browser requesting updates is ironic compared to anything else that happens.

As for the whole idea of using bookmarks, I agree with you – it seems to make a decent amount of sense. However, I do think that a microformat would be a much greater step froward, giving not only users easy / useful ways to access Ubiquity commands, but also giving developers chances to do what they like with them.

Code versioning is difficult short of having to replace bookmarks unless there is a dynamic mechinism for updating bookmarks given uses an option to upgrade or not (not difficult, add a CmdUtil function in the case of Ubiquity with the upgrade URL).

Security again can be simply handled by storing a local Hash of the script which will detect changes alerting the user. This will prevent malicious code changes going unnoticed.

So far I’m yet to see a down side except for bandwidth and load times which are becoming less and less an issue.

Bookmarklets, being explicitly invoked, also have the (substantial) benefit that they can’t mess your system up. I’ve had bad experience with several extensions and Greasemonkey scripts, and the inability to really understand the problems is what leads to a general suspicion.

But Songbird seem to be doing some interesting things with XUL in this regard, openign up their chrome to website etc.

Extension development and the desktop paradigm definitely have a high cost of adoption. XUL itself, on the other hand, has a very low cost of adoption for anyone already familiar with HTML. Indeed, in my experience, basic XUL is significantly easier than HTML simply because Gecko is the only target, so there’s no need to know about cross-browser issues, and it’s safe to use more modern functionality that is missing from some other browsers.

The problem is partly that _remote XUL_ doesn’t receive much love and attention. In theory it should provide a great way for an existing web developer to create something more application-like, quickly and easily, whilst leveraging their existing knowledge of XML, CSS, JS and so on.

In practice it has too many artificial restrictions, which mean that in many aspects remote XUL is even more locked down than a normal web page. To make matters worse, a lot of these limitations aren’t clearly documented.

Remote XUL could be a great option for bookmarkable extensionsn (and other uses), if only it were a slightly higher priority in Mozilla’s eyes.

So … imagine if the browser chrome was a website, chrome.mozilla.org, that the browser was hardcoded to display. Then you could install extensions by re-setting your chrome to chrome.mozilla.org/extensions/1843;5579 (if you wanted Firebug and PicLens).

But changing chrome favourites is different to setting content favourites. It’s a different user experience, a separate category that is always restricted to the mozilla domain.