W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: [WebIDL] remove modules

From: Robin Berjon <robin@berjon.com>
Date: Tue, 23 Aug 2011 15:58:33 +0200
Cc: <public-script-coord@w3.org>, Anne van Kesteren <annevk@opera.com>
Message-Id: <AE607D8D-34D5-4BFE-ADA5-740678A93D67@berjon.com>
To: Bryan Sullivan <blsaws@gmail.com>
Hi Bryan,

On Aug 11, 2011, at 15:59 , Bryan Sullivan wrote:
> If modules are removed from WebIDL, how will different specifications ensure
> that there are no namespace issues (i.e. conflicts between the names of
> interfaces)? Sorry if I am misunderstanding the intent of the module
> feature, but that is one aspect of how it was used in BONDI (which still
> does exist it the market, BTW, in products but not as an actively developed
> specification) and WAC.
> 
> I am very interested in the stability of this spec, for WAC and also because
> I am leading work to begin using Web IDL in the Open Mobile Alliance, in
> which we are creating Javascript APIs for exposure of OMA enabler services.
> We will have a variety of APIs being defined, and need to ensure that the
> different specifications do not conflict in the naming of interfaces.
> 
> Without the module feature, how do we replace the capability for this
> purpose?

I don't think that modules help BONDI, WAC, and OMA as much as people there think that they do. I also think that there's a workaround.

The requirement that I believe you have is that you should be able to add new interfaces to Web runtime engines without them clashing now or ever. So for instance if WAC creates an interface for toasters without anyone complaining, but ten years down the line W3C, browser vendors, etc. realise that they badly need toasters too no clash happens.

You don't need modules for that, you just need some kind of namespacing. You could go really low-tech on this and all anything globally available you have WACSomething (e.g. WACToaster) but that gets tired fast and ugly faster. I think that your best design approach is to create one single global (unlikely to clash) for the entire organisation and place all your additions there. Effectively, it's a module but you can implement it using just interfaces. So you have a supplemental WACWindow that adds .wac to window, and then a supplemental Toaster that adds .toaster to .wac.

Does that make sense?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 23 August 2011 13:59:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC