A little walk down memory lane : In defense and condemnation of Microsoft

I have always been a vocal proponent for the implementation of javascript in the client with the intent to push processing cycles out unto the client machines, to reduce the hurry-up-n-wait, to reduce bandwidth and load on the server and increase it's ability to handle more concurrent sessions, to realize the vastly scalable thick-client application.

Indeed, it was Microsoft's Internet Explorer version 4.0 (released in beta and final through 1997) that was turning point for me. With it's improved support of CSS, Dom, Javascript... the fundamental changes that integrated it with the OS and Windows domain security... the new functionality that distinguished itself (from Netscape) as the "real" browser.

But there was something beyond all those features, something that we take for granted today that really turned my crank, that really converted me into a serious Microsoft acolyte. It drove me to study like mad and achieve Microsoft certifications at a furious pace.

The little feature was called Remote Data Services (RDS), an Active-x object that you could embed in your html and access via [java]script. It could be used to fetch data from a server, via script, without requiring a refresh of the page and waiting for all the redundant data on a page to be retransferred over the puny pipes of the 33.8k modems available at the time. [Note: I have always been like Ebenezer Scrooge about data transfer since my formative years as a 16-year old kid driving my parents nuts running a Wildcat Dungeon and Dragons bbs in the evenings using a 300 baud accoustic coupler connected to my father's IBM 8086 - sloooooow.] It meant a new breed of applications could be built, delivered via the web, that would connect you to the world with the ease of simply visiting a webpage.

I found many uses for it whilst working for a large bank in Canada that (wisely) implemented Internet Explorer version 4.5 throughout their entire infrastructure. Mostly in updating parts of pages to display near real-time data or to populate components of a form as the user completed them. I cannot recount how many times I used RDS to populate select lists in a form as the user selected an item higher in the hierarchy; think Country - State/Provice - City - etcetera...

It was during this time I tried to coin my own term for this kind of application: the "rich client". It didn't stick with anyone and thankfully, someone else popularized "thick client" which was the perfect term for a concept that stood between "thin client" and "fat client". It is my feeling that we have Microsoft to thank for the innovations that allowed us to conceive and realize the "thick client". It wasn't perfect but it was a reasonable start that you could realize solutions with. But Microsoft didn't stop there.

They followed with Internet Explorer 5 that, in addition to improved CSS, javascript, and XML/XSLT, included a new ActiveX object called XMLHttpRequest to which many attribute the birth of AJAX (coined many years later). Microsoft's dominance in the browser wars was clear and deserved as they were the innovators of the day - paving the way to Web 2.0.

Today, Microsoft has taken years of beatings for their browsers that stood still and ignored innovating standards years later. Versions 6, 7, and to a lesser degree version 8 all forced designers to hack and double-design CSS for multiple browsers - a painful exercise and all Microsoft's fault for trying to write it's own standard.

Finally, in version 9, and in recognition of HTML5 (and the obvious opportunity to kick Flash out of the marketplace), and the realization that they have lost the battle for control of the standards helm, Microsoft has finally released a beta that complies with standards as much or more than it's competitors.

But, I warn you, do no let the Microsoft harassment end - there is still a vast installed base of versions 5.5, 6, 7, and 8. You'll find them on Gramma's computer or on the majority of computers hosting pirated copies of Windows (found largely in the developing world).

Microsoft has been very lax about updating the installed base of old browsers claiming that they should not be expected to update browsers on pirated versions of their software. I'm sure the hackers of the world rejoice daily that there still remains a huge base of infected or infect-able machines. Designers cry when usage numbers point to still significant numbers of these browsers in the market place and are forced by their employers to "support it all".

While I congratulate Microsoft for finally doing the right thing and properly supporting standards, and I continue to respect them for their past innovation towards what we now refer to as Web 2.0, I demand that they clean up the mess they left, pirated or not, and update older browsers to version 9 on all machines possible. This old mess is their sole responsibility.

Same Origin Policy Needs to Evolve : X-CROSS-DOMAIN

Same Origin Policy (SOP) is an important one - it protects us from fraudulent phishing and spoofing attempts where a malicious website or trojan can emulate a website, such as an online banking site, and gain access to usernames, passwords, and other sensitive data. This type of attack has been referred to as Cross Site Request Forgeries.

But there are some instances where a web service may desire it's web service data to be shared - we need a way to indicate (to browsers) that a given web page (or webservice) may cross domain boundaries with permission from the source. The problem is that SOP (needlessly?) hampers our ability to create mashups using XmlHttpRequest object. Instead, we need a new solution - a new policy.

Crockford has been pushing for JSONRequest, a new object that can already be seen in some browsers and, according to Crockford, doesn't require Same Origin Policy enforcement because JSON data is benign.

JSON, while wildly popular, is merely a subset of Javascript's Object Literal Notation - less being able to pass functions. Crockford has omitted functions from his vision of literal notation (JSON) in order to render it powerless to execute. And, when parsed and checked as valid data by the JSONRequest object thus, an exception to the Same Origin Policy because it is supposedly "benign". It is tantamount to stealing functionality, originally given to us by the designers of Javascript and I am not in favor of it.

Instead, imagine a a world where web-service operators could mark their webservice with the header X-CROSS-DOMAIN to allow mashups to use it freely. To cover their costs of transferring vasts amount of data, some web-service operators might wish to include advertising along with it's "free" data. It is not unreasonable to suggest that a web-service operator, who must incur the data transfer cost of delivering data to various mashups, might desire to be recompensed with some advertising. Passing a self-executing function within the object literal notation (as envisioned by the creators of Javascript) might give them the ability to pass a splash advertisement on the receiving web page.

I realize that no-one likes advertising but it is a model that we have accepted in so many other mediums for free content. Nothing is for free in this world - and if we can encourage web-services with valuable content to be shared en-masse, albeit perhaps with advertising, we improve the web.

So, we don't really need another data fetching object in Javascript - XmlHttpRequest is robust and fully supported in most browsers. We don't really need JSON - object literal notation already exists. We also do not need a new policy, Same Origin Policy makes sense to protect us from websites that might spoof other websites.

What we need are Same Origin Policy exceptions. The evolved policy must allow for web servers to supply an exception header that affectively says: "This document may cross domains" so that the "REST"ful webservices can be accessed using the methods intended instead of relying on only GET (why should we be reduced to using GET when we want to POST or DELETE or PUT? Let's realize Tim Berners Lee's original vision of the web and not get side-tracked into all sorts of strange meanderings - remember SOAP?!?)

The browsers could start by implementing this exception when the expected header is found (using a HEAD request), thus allowing the content. Then application developers can make use of the header in most server handler environments. Later, server software like IIS, Apache, TomCat, etc, can allow server administrators to explicity specify which files and folders are cross domain permittable (overriding any handlers made by developers).

To illustrate it clearly, I would first like to propose the use of the non-standard header: X-CROSS-DOMAIN

The data associated with the header may be a URL for which the cross domain exception is made, or simply the text 'all' to indicate the document may cross to all domains. Further on, there might be an allowance for multiple domain listings, separated by commas. Furthermore, we might block or blacklist URLs using the minus sign in front of the offending URL. Examples might appear like this:

X-CROSS-DOMAIN: *
- requests from any domain may be permitted

X-CROSS-DOMAIN: http://reinpetersen.com, http://perukitemancora.com
- requests from reinpetersen.com or perukitemancora.com may be permitted

X-CROSS-DOMAIN: http://blog.reinpetersen.com/2008/10/interface-in-javascript.html
- requests from the specific URL http://blog.reinpetersen.com/2008/10/interface-in-javascript.html may only be permitted

X-CROSS-DOMAIN: *, -http://hackthissite.org
- all requests may be permitted except hackthissite.org

For this to work, browser support for this header must exist first. The support would be built on the XmlHTTPRequest object. Once the support in browsers exists, web developers will be able to customize their (JSON or XML) webservices to include the X-CROSS-DOMAIN header in the response in order to allow their data to be used (effectively) in mashups around the web. Mashups can continue to use the existing and robust XMLHttpRequest to GET,PUT,POST,DELETE,HEAD, and TRACE data located on various servers around the web.

As mentioned, later on, web server software can eventually include server administrators in the process, allowing them to assign X-CROSS-DOMAIN policy exceptions through standard security interfaces instead of programmatic-ally through code.

A similar measure (in intent), albeit unnecessarily verbose and potentially a massive security hole, was adopted after I wrote this article but before I published it. This article is an evolution of one I wrote many years ago [ http://slashdot.org/journal/137429/A-solution-for-cross-site-scripting ] that is no longer hosted - this article responds to some alarming trends that should be I feel should be "nipped-in-the-bud"

In version 3.5 (and greater) of Firefox, a new Request header (not a Response header such as I am proposing here) called 'Origin' permits XMLHttpRequest object to obtain cross-site data leaving the onus on the web server to enforce it (should there be need for a blacklisting of a given website). You can read more about it here: https://wiki.mozilla.org/Security/Origin and the original draft at: http://tools.ietf.org/html/draft-abarth-origin-05 and the Cross-Origin Resource Sharing working draft it was based on at: http://www.w3.org/TR/2009/WD-cors-20090317/

Because Same Origin Policy is enforced in the browser, and not at the Server, we cannot remove the enforcement at the browser unless the Server tells us this is alright. Neither can we assume that Web servers will adopt this fully, if even at all. From my experience, having written small http servers and handlers, is that there are many (1000's perhaps 10,000's) web-services that will have to re-written to support the Origin request header to deny cross-origin requests when this support was already supposed to be guaranteed by Same Origin Policy supported in all browsers.

In version 3.5 of Firefox, a hacker who has installed a trojan on your computer or has somehow lured you to his site with a crafty URL (perhaps in an email), can spoof any website that hasn't already retooled its web server to handle the Origin specification (in draft status and yet to be accepted). All because a web-service operator wanted to share his web-service to the world but didn't have the wherewithal to program a denial of service response based on Origin for unwanted abusers of the service in timely manner..

Granted, it seems Mozilla has supported the white-listing Server response header Access-Control-Allow-Origin but this is still a problems as it only a whitelist - there is no way to blacklist specific offenders. Thus, if you want to share your resource to many but you have one bugger doing dasterdly deeds with your data, you'll have to white-list everyone sharing your data - potentially a big list.

Furthermore, pushing the responsibility of deciding what can be served based on the Origin request header data onto the server is extraneous. The client (browser) is fully capable of determining what exceptions are possible based on the server's list of exceptions (or non-exceptions) to Same Origin Policy. Remember, we are trying to push processing out to the leaf nodes in this age of increasing computing power in the hands of users and increasing demand on servers.

While attempting to solve the same problem, Mozilla has followed a route (CORS) that is rather backwards in regards to sharing resources across domains. The onus remains on the browser to maintain Same Origin Policy and the only exceptions that should be made should be dictated by Servers, ideally through a header as I have demonstrated in this article.

What the 'Origin' header really does is force web servers to process the header and decide if it can share the resource or not. Rather, the solution should be an 'opt-in', as I have demonstrated with X-CROSS-DOMAIN, where a web server can claim a given resource may be freely mashed (or specifically denied) into other websites (perhaps with advertising intact) and the browser can loosen the Same Origin Policy only when it has this permission within the header of a resource.

A work-around for a common Inheritance problem in Javascript

Inheritance in Javascript is a well-documented concept found on the internet. There are quite a few ways to do it but most solutions generally involve prototyping in Javascript. But there are caveats and to understand them, I will demonstrate how Inheritance is typically achieved (through JavaScript prototyping).

Javascript, arguably, supports a form that mimics Class Inheritance through the use of the prototype property accessible to all objects. Remember that in JavaScript, everything is an object, even a function. If you choose to define your "class" using a function, it is actually an object. JavaScript does not support classes but we are still able to model our scripts in an object oriented manner that is good for code reuse, fast execution, and legibility. So first, let us define our "class" (emulation) that will let us extend the GMap2 "class" found in the Google Maps API:

function GMap2Extension(){}

GMap2Extension.protytype = GMap2;

That is all there is to defining and deriving one "class" from another in JavaScript. It is actually a function, which in JavaScript is also an object. But it behaves like a class in most respects in that it has a constructor that can accept arguments and may define public, privileged, and private properties and methods. [Class emulation in JavaScript is beyond the scope of this article but you can find out more about it in another article I will be posting soon or elsewhere on the net.]

That said, again there are a few caveats to watch out for. In this article I will demonstrate a particular problem that relates to extending (sub-classing or inheriting from) JavaScript "classes". The first problem is that the base "class" (function) ((object)) is expecting arguments to be passed into the constructor and may fail (error) without them. So, we need to supply the arguments (parameters) to the the base "class" constructor by rewriting our GMap2 extension "class" (function) ((object)):

function GMap2Extension() { GMap2.apply(this, arguments); }

In the above example we have used the 'apply' function of the GMap2 to do this for us. The 'arguments' parameter is a property available all objects that supplies an object similar to a dictionary. It is simply a dictionary-like object containing all the arguments presented GMap2Extension "class" (function) ((object)). The 'this' parameter is a special JavaScript keywords that refers to the object in-scope, in this case, it will be a GMap2Extension instance (when the constructor is called with the 'new' keyword.

You'll notice I did not supply named parameters in the definition of the GMap2Extension "class" (function) ((object)). In JavaScript, a loosely-typed language, it is unnecessary but here it is with the parameters defined:

function GMap2Extension(container, opt_opts) { GMap2.apply(this,arguments); }

The parameters 'container' and 'opt_opts' simply mirror those found in the GMap2 function definition. If you wanted to overload the constructor to allow you to pass extra arguments for processing in your own constructor, you might compose the function as follows:

function GMap2Extension(message,container,opt_opts) {
this.message = message;
GMap2.apply(this,{"container":container,"opt_opts":opt_opts});
}

Next, we'll examine more closely the use of the prototype property, available to every object in JavaScript, to extend the "class". The prototype property accepts an object and, since a function is an object and we use functions to emulate classes, we can pass a function to the prototype property. JavaScript will copy all the properties from the object (function) (("class")) assigned to the prototype property to itself:

GMap2Extension.prototype = GMap2;

Ok, so it seems our GMap2Extension "class" is ready to go - we'll just instance it using the 'new' keyword and assign it to a variable (once all the objects required to be passed into the constructor have been created):

var mapelement = document.getElementById("mymap");
var mymap = new GMap2Extension("welcome to my map",mapelement); //opt_opts is optional

Everything was looking good, until we execute. It errors. It seems the properties and methods within the GMap2 class cannot be found and there is a good reason for this. Google has wisely placed private and privileged methods and properties within the constructor of their important objects to ensure that there are no accidental (or malicious) usage of these special members.

The only problem is, the subclass, with it's prototype set to GMap2, what is actually stored is an object returned from it's constructor. The base (GMap2) object stored in the prototype no longer has access to it's constructor because it is out of scope and now, the object stored in the prototype property no longer has access to those special members and it cannot complete it's work - it only has access to the public properties.

Another option is to supply the prototype with a new instance of the GMap2 "class". While that may work in other instances, in the case of GMap2, it may be constraining having to know in advance which element will be passed and to not have the freedom to change that. This option is not our solution if we need the freedom to change the map element.

An alternative is, while continuing to use prototyping, we will pass on prototyping the constructor and opt just to prototype the various properties of the GMap2 object:

GMap2Extension.prototype = GMap2;
for(var prop in GMap2.prototype) GMap2Extension.prototype[prop] = GMap2.prototype[prop];

This will give us access to all the properties of the (implicit) base class. The shortcoming with this solution is that a GMap2Extension instance will never evaluate to being an 'instanceof' a GMap2 object - regrettable and unfortunate. However, in a language like JavaScript, duck-typing ("if it walks like a duck...") is pretty common and can give you an edge in other ways that strict-typing cannot.

But we're not satisfied with that - we want to know in our code what base a subclass is derived from. Fortunately, there is another way. Using closures in JavaScript ( a function within a function) we can keep the private and privileged members found in the constructor of the base class alive long after the original constructor has gone out of scope and been garbage collected - as long as we maintain references to the closures. We'll do this with an global function:

function extend(subclass, base)
{
function Closure(){}
Closure.prototype = base.prototype;
subclass.prototype = new Closure();
subclass.prototype.constructor = subclass;
subclass.base = base;
}

function GMap2Extended(message,element)
{
GMap2Extended.base.call(this, element);
this.enableContinuousZoom(); // the GMap2 methods are available
this.mymessage = message;
}

extend(GMap2Extended, GMap2);
var mymap = new GMap2Extended("My map!",document.getElementById("map"));

alert(mymap instanceof GMap2); // alerts true

This works but I wasn't happy with what seemed to be an unnecessary global function. I felt it should be tucked away in a better place and, since Function is also an object, I decided that was where the extend method should reside:

Function.prototype.Extends = function(base){
function Closure(){}
Closure.prototype = base.prototype;
this.prototype = new Closure();
this.prototype.constructor = this.constructor;
this.base = base;
}


You'll notice that there is a new property added: 'base'. For the time being, and until JavaScript version 1.91 is found commonly on most browsers, we are stuck keeping our reference from descendant to ascendant. While the prototype chain exists and might be able to provide that information, we have no way of teasing the type from the object stored in the prototype without at least knowing what it might be before hand. Adding this property ensures that we know exactly which class another derives from. And, we can use this new property to pass arguments to the constructor of the base class. Now extending a base class seems a little more elegant and we're not stuck with a messy global function:

function GMap2Extended(message,element)
{
GMap2Extended.base.call(this, element);
this.enableContinuousZoom(); // the GMap2 methods are available
this.mymessage = message;
}
GMap2Extended.Extends(GMap2);
GMap2Extended.extends(GMap2);
extend(GMap2Extended, GMap2);

var mymap = new GMap2Extended("My map!",document.getElementById("map"));
alert(mymap instanceof GMap2); // alerts true

Interface in Javascript

While there are other suggested ways to emulate Interface in JavaScript, I prefer the method I demonstrate (below) because of it's simplicity. If you really want strict enforcement, you'll need a system that implements decorators (see Decorator Pattern) which may provide strict[er] enforcement at run-time but ends up looking a little less than elegant (note the sarcasm).

For my purposes, I just want to assist development of complex JavaScript solutions by reducing complexity and avoiding inadvertent mistakes. This is not a solution that ensures strict enforcement nor are any of the solutions I put forth in writing JavaScript in an OO manner.

In OO terms, an Interface is a contract by which the implementing class (or in the case of JavaScript, a function) adheres. An Interface describes a desired behavior and enforces adherence for any Class which implement the Interface. Implementing interfaces, again in OO terms, is like saying OneClass 'IS LIKE A' NutherClass, or more correctly 'PROMISES TO BEHAVE LIKE', in contrast to Inheritance where you might say that a DerivedClass 'IS A' BaseClass.

As JavaScript applications are becoming increasingly complex with multiple team members participating in the design and construction process, we need a means to enforce the Interface contract beyond just commenting the JavaScript code. The Interface is common in many design patterns and, while we can omit it's use, the consequences are that the programmer[s] must remember all instances where they intend to implement a grouping of functionality or behavior.

Since the Interface is not available in JavaScript, we are forced to emulate it in the most elegant and functional manner we can through JavaScript (read as 'duck typing'). Here for your benefit is my take on a simple way to emulate the Interface in javascript:


function Implements(implementer,pseudoInterface)
{
for (prop in pseudo)
for (prop in pseudoInterface)
if (typeof pseudoInterface[prop] === "function" )
if (typeof implementer[prop] != "function")
throw new Implements.FunctionNotImplemented(implementer.constructor.name,prop,pseudoInterface.constructor.name);
}

Implements.FunctionNotImplemented = function(implementing,implemented,pseudoInterface){
this.implementing = implementing;
this.implemented = implemented;
this.pseudoInterface = pseudoInterface;
};
Implements.FunctionNotImplemented.prototype.message = function(){
return this.implementing + " does not implement function: " + this.implemented + " as contracted in psuedo-interface: " + this.pseudoInterface;
};

function IUpdateable(){}
IUpdateable.prototype.update = function(){};
IUpdateable.prototype.sendupdate = function(){};

function myClass()
{ Implements(this,new IUpdateable());
}
myClass.prototype.update = function(){ alert("this object had it's update method called"); }

function main()
{
try { var myobj = new myClass(); }
catch (e if e instanceof Implements.FunctionNotImplemented) alert(e.message());
catch (e) alert("cannot handle exception: " + e.String()); // log error
}

Notice that it is only at instantiation of the object implementing the interface that a check is performed. You may very well be running code and never see your error unless the offending implementer is instantiated and fails to implement the methods defined in the interface. If we attach our logic to the prototype of Function, we can resolve this problem and also do away with messy global declarations. While we're at it, I'm going to add the ability to implement multiple Interfaces:

Function.prototype._Implements = function(pseudoInterface,opt_options){
for (prop in pseudoInterface.prototype)
if (typeof pseudoInterface.prototype[prop] === "function")
if (typeof this.prototype[prop] != "function")
throw new Function.MethodNotImplemented(this.name,prop,pseudoInterface.name);
};

Function.prototype._ImplementsArray = function(interfaces,opt_options){
if (interfaces instanceof Array)
for (item in interfaces.reverse())
if (typeof interfaces[item] === "function")
this._Implements(interfaces[item],opt_options);
else throw "The Array supplied contains an item that is not a Function";
else throw "The parameter supplied is not an Array";
};

Function.prototype.Implements = function(interfaces,opt_options){
try {
if (interfaces instanceof Array) this._ImplementsArray(interfaces,opt_options);
else if (typeof interfaces === "function") this._Implements(interfaces,opt_options);
else throw "The parameter 'interfaces' supplied was not an Array or Function";
}
catch (e)
{ alert(e.toString()); }
};

That is all well and good but you may have noticed that the implementing object bares no relation to the implemented interface. In other languages, like Java or C#, we can perform a type test to ask if an object IS of a type it has implemented which will result in true. In this way, implementing interfaces behaves like multiple inheritance. Our solution above will not respond the same way with JavaScript instanceof. Because the prototype chain cannot be branched (it is a one-to-one, child-to-parent relationship), our Interface solution appears more like a pseudo-Interface.

Of course, we could insert the Interface(s) at the top of the prototype chain but if our implementing class(es) were derived from classes not implementing the interface, errors would be thrown and brittleness introduced into the solution. This would become, certainly, more of an issue were one deriving from classes in an external package (such as the Google Maps API) where we have no (classical) means to ensure due diligence in regards to the contract defined by an Interface.

Yes, JavaScript is unique in it's flexibility and we can simply add methods (properties with a value of a function) to the prototype of the, for example, GMap2 function. But that is contrary to legibility where, in the case of Google Maps API and other external API's, the package is opaque (through obfuscation, compression, and in some cases encrypted) aside from the public documentation.

Again, JavaScript is unique in this ability but the well-rounded programmer uses several languages that when aggregated, can and should be composed complying (where possible) to a common or similar form within OO style.

Yet I'm still unsatisfied with our inability to use instanceof in detecting a class that implements a given Interface. The solution is to write our own instanceof and attach it to the prototype of Object:


Object.prototype.isInstanceOf = function(pseudoInterface){
if (this instanceof pseudoInterface) return true;
else
{
try { this.constructor.Implements(pseudoInterface); return true; }
catch (e) { return false; }
}
};


And there you have it, a not-too brittle means of implementing interfaces in JavaScript.