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

[whatwg] Browser Bundled Javascript Repository

From: Chris Holland <frenchy@gmail.com>
Date: Mon, 15 Jun 2009 14:07:51 -0700
Message-ID: <8da6ad500906151407q5d5b1614s5db70990a3c7d90c@mail.gmail.com>
If you build a Firefox plugin, you can put some code on your page that
allows users to "click to install" if the user doesn't already have
the plugin installed. If you ship an updated version of your plug-in,
users get notified and prompted to install the new one.

Similar mechanisms exist on other browsers.

But you're right, this is all a lot of end-user intervention: it would
be a slightly, err, very painful process of installing a browser
plugin, which is currently very-much of a user opt-in process, and not
something very practical.

However, the underlying plugin infrastructure could be extended for a
more transparent process built specifically to handle browser
javascript library extensions. I'm just trying to find ways to
leverage a lot of what's already there.

On the web developer's end, one might consider:

Instead of adding an attribute to a script tag, the good old' <link />
element could be both backward and forward compatible:

<link rel="local:extension"  type="application/x-javascript"
href="ext:ibdom.0.2.js" />
or
<link rel="local:extension"  type="text/javascript" href="ext:ibdom.0.2.js" />

instead of a "chrome://" prefix, some new protocol to specifically
designate a local extension would likely be more appropriate. I'm
throwing "ext:" out there for now.

Interesting thing is the same scheme could be leveraged for local CSS
extensions:

<link rel="local:extension"  type="text/css" href="ext:ibdom.0.2.js" />

To handle users who don't have the "ibdom" javascript extension
installed, developers could add something like this to their document:
(assuming a decent library which declares a top-level
object/namespace):

<script type="text/javascript">
if (!window.IBDOM) {
var newScript = document.createElement("script");
scr.setAttribute("type","text/javascript");
scr.setAttribute("src","/path/to/ibdom.0.2.js");
document.appendChild(newScript);
}
</script>

-chris

P.S.: http://ibdom.sf.net/


On Mon, Jun 15, 2009 at 12:53 PM, Joseph Pecoraro<joepeck02 at gmail.com> wrote:
>> Library vendors would then ship their releases as browser plugins, using
>> existing discovery mechanisms, as well as software update mechanisms.
>>
>> -chris
>
> This sounds to me as though the user would have to download a browser
> plugin. ?I would hope this would be as transparent as possible to the user.
> Maybe I'm misunderstanding the discovery mechanisms you're talking about.
> ?Could you expand on this?
>
> I do think that a URI prefix is a neat idea. ?This could eliminate the need
> for a new attribute. ?Is it as backwards-compatible?
>
> - Joe
>



-- 
Chris Holland
http://webchattr.com/ - chat rooms done right.
Received on Monday, 15 June 2009 14:07:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:13 UTC