[OpenAjaxIDE] Microsoft Ajax metadata format quick start guide

Bertrand Le Roy Bertrand.Le.Roy at microsoft.com
Thu Jul 12 12:33:29 PDT 2007


Hey,

Let's get the IE issue out of the way first. I represent Microsoft here, but I still have limited influence on the IE team's designs, much to my regret. As a matter of facts, we as a team (Microsoft Ajax) have long ago already relayed to the IE team the very same concerns and wishes that you express below. I believe MSN/Live also has expressed similar thoughts. I do not know at this point whether they will take those into account in the near future. Anyway, we all know we have to deal with IE6 and 7 for some more time so while I agree we should do what we can to push the browser forward (and I encourage you to send my way any other suggestions you have, I *will* relay them), we need to solve today's problems on our own.

The main point I'm trying to make is that today we probably don't have a clear idea of the typical global objects that existing libraries use. We exposed ours and it's a long list for various reasons. One of the reasons is that our customers typically build on top of ASP.NET which has its own legacy of global object from a time when the very idea of a mashup didn't exist outside of the brains of a few visionaries (afaik). We have to maintain those, it's our responsibility to our customers and in some cases I understand we are even legally bound to do so. I'm not making excuses here, just exposing one problem that we have and that I suspect others may have too.

In the end, we have two solutions. We can ban any extension to anything that's not window and that you don't own, or we can create this registry as a way to manage conflicts.
I think only the second approach can be successful.

Regards,
Bertrand

-----Original Message-----
From: Alex Russell [mailto:alex at dojotoolkit.org]
Sent: Thursday, July 12, 2007 12:05 PM
To: Bertrand Le Roy
Cc: ide at openajax.org
Subject: Re: [OpenAjaxIDE] Microsoft Ajax metadata format quick start guide

Hey Bertrand,

On Thursday 12 July 2007 11:08 am, Bertrand Le Roy wrote:
> Hi,
>
> That subject was discussed at yesterday's meeting.
>
> Actually, it's a fact that many existing and widely used frameworks
> extend built-in prototypes and instances.

Hence we have a problem that needs solving. That it is so today creates no viable case that it *should* be so or that we as a body have any business sanctioning such interoperability-destroying practices.

> Even frameworks that make a
> major point of having minimal impact on the global namespace actually
> introduce potential conflicts in ways that are not always easy to see.
> For example, it's common practice to have APIs that query the DOM and
> return DOM elements that are mixed-in with additional functionality.

Lets be VERY clear about this: toolkit vendors do this because IE does not allow any useful form of subclassing of DOM elements. Dojo provides a widget system and the NodeList classes for this very reason (we wrap but never extend). Other browsers have some means of DOMElement subclassing although they are far from ideal or coherent at this point.
Every toolkit vendor I know would like to have this fixed, but so far MSFT has neither shared any data about IE.next WRT this issue (or any others), nor have repeated calls for a solution to this issue been heeded in previous IE releases. Perhaps you can press the case internally?

> Do you also want to prohibit that?

I'm in favor of documenting these hacks and noting the interop pitfalls.
That said, what you're describing only happens once a node is "owned"
by a block of code, it's not a global, de-facto and by-default behavior imposed on every node in the system. It is, clearly, a distinct and separate question from that of root object prototypes.

> I think it's a fact
> that built-in objects will be extended because it's very useful to do
> so.

It's this body's job to set standards for interoperability, not to condone a race to the bottom.

> I'm sure Dojo does a much better job than we do at never adding an
> expando to any object that it doesn't own but we chose to be very open
> about everything we had so that we can spot problems that are likely
> to be found in other libraries too.

Dojo is not (and never has been) 100% "clean". What OAA needs to do is to set standards that libraries need to meet. Setting them high is a point of leverage in getting toolkit vendors (Dojo included) to do the right thing. Dojo only has less work to do because we knew these standards were coming when we sat down to do 0.9. I actually think that's a great case for why we should set the standards high.

> You could take the approach of prohibiting everything but the likely
> result would probably be that toolkit vendors would just go "ok, fine,
> we won't be OpenAjax-compliant then" rather than break their
> customers' applications. I don't think that's what we're trying to
> achieve here.

Fair enough, but this one is straightforward and has known interop issues which aren't discoverable except at runtime in composed systems.
It's hell to debug and easily avoidable through social pressure on vendors.

> The goal of the registry as far as I understand it is to manage
> conflicts while allowing the flexibility that is required by existing
> art.

Yep. I think the resolution would need to be something like "we'll accept these 10 but not these other 5, therefore you can't claim to "own" them and must warn your users about them". That seems equitable to the state of the art.

> I think it would also be useful if the Alliance provided guidelines in
> the form of "SHOULD" recommendations such as "libraries SHOULD NOT
> extend Object.prototype or Array.prototype". Whether they should
> extend instances of DOM elements

Note the terminology here. "instances" vs. "prototypes". If root DOM Node prototypes were exposed sanely across browsers, I'd be advocating just as strongly against extensions to them. Instances are a different ballgame than prototypes.

Regards

> or prototypes of other objects is
> still, I believe, a subject to debate in the community and certainly a
> common practice so if we provide recommendation here it should
> probably be to limit the number of extensions rather than prohibit
> them entirely. Let's focus on making the registry a useful tool to the
> community instead of trying to impose rules that are too restrictive
> to be followed.
>
> Thanks,
> Bertrand
>
> -----Original Message-----
> From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On
> Behalf Of Alex Russell Sent: Thursday, July 12, 2007 10:15 AM
> To: ide at openajax.org
> Subject: Re: [OpenAjaxIDE] Microsoft Ajax metadata format quick start
> guide
>
> On Thursday 12 July 2007 7:46 am, Jon Ferraiolo wrote:
> > Hi everyone,
> > Bertrand has sent in some emails describing the list of globals and
> > JavaScript extensions that MS Ajax uses, along with the XML format
> > used to document the runtime JavaScript used by MS Ajax. I have been
> > going through some of these documents and I found it a bit hard to
> > figure out where I could find an executive summary and some
> > examples. Here is what I found:
> >
> > Executive summary of XML metadata format:
> > *
> > http://weblogs.asp.net/bleroy/archive/2007/04/23/the-format-for-jav
> >as cript-doc-comments.aspx
> >
> > List of JavaScript globals and JavaScript extensions used by MS
> > Ajax: * http://openajax.org/pipermail/interop/2007q2/000168.html
>
> Ouch...that's a long list. Are we going to allow any vendor to
> "register" globals which extend root object prototypes? I had thought
> that the consensus was "no", and that they should be flagged as
> dangerous and potentially conflicting (otherwise interop is a joke).
>
> Regards
>
> --
> Alex Russell
> alex at sitepen.com     A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894
> 6876 alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242
> 59C3 9723

--
Alex Russell
alex at sitepen.com     A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723



More information about the IDE mailing list