Browser Wars

A long time ago, in a galaxy far far away...
No wait!! That's another set of wars that we are talking about here, one that does not involve lightsabers and droids. According to Wikipedia, the term "Browser Wars" refers to the competition for dominance in the Web browser marketplace. So far, there has been two major browser wars:

Browser War I (late 1990s)

Main opponents: Netscape Navigator (aka Netscape Communicator) and Microsoft Internet Explorer (IE)

Highlights:
In order to compete, the two browsers kept on adding features to one-up each other. Each browser had its own implementation of JavaScript (which were not compatible). Each browser had its own set of supported non-standard HTML tags. Adding new features had higher priority over fixing bugs, which resulted in both browsers being somewhat unstable.

Microsoft delivered the winning blow by integrating Internet explorer with its Windows operating system, which made the browser readily available to every Windows user - a move that was broadly criticized.

Effect on the Web experience:
BW-I was a time of Web chaos: shaky Web-standards compliance, frequent browser crashes, and many security holes. It was hard to design Web-sites that could behave similarly on both browsers, and thus it was common for Web designers to display 'best viewed in Netscape' or 'best viewed in Internet Explorer' logos. Some Web-sites even went as far as to work only on one browser or the other. This was indicative of the divergence between the "standards" supported by the browsers and signified which browser was used for testing the pages.

---

Browser War II (2003 - present)

After Netscape was defeated, they open-sourced their browser code, which led to the formation of the Mozilla Foundation — a community-driven project to create a successor to Netscape. After several years, the new browser "Firefox" was born (version 1.0 was released on 9 November 2004). Since then it has continued to gain an increasing share of the browser market, and became the main competitor against Internet Explorer.

Other contenders joined the war at different points in time, including (but not limited to) Opera, Safari, and the most recent contender, Google Chrome.

BW-II differs from BW-I in a major aspect: The contenders try as much as they can to work under the umbrella of the Web-standards. All browsers have compatible JavaScript engines (except for minor differences), and support more-or-less the same set of widely-recognized HTML (or XHTML) tags. Whenever a new feature is added to a browser, it soon becomes an expected feature in all the others (e.g. tabbed browsing, pop-up blocking, phishing filters, etc.). The contenders compete mainly in the following areas:

• Browser speed (the time it takes to load pages)


• Resource usage (amount of Memory and CPU needed)


• Stability


• Security (vulnerability to malicious code, holes that can be exploited, etc.)

Until the moment of writing this post, Internet Explorer still has the major market share, but the other browsers (particularly Firefox) are more popular particularly within the IT industry professionals because of serious security flaws in IE, in addition to some of the unique features provided by the other browsers (e.g. Firefox's support of custom extensions, and the multitude of such extensions available online, which makes it possible to personalize the browser to each user's needs). Also, IE seems to be falling behind in terms of browser speed. In a recent browser benchmark comparison done by gHacks.net, IE proved to be the worst among all tested browsers.

Effect on the Web experience:

Unlike BW-I, the current browser war is proving to be in the best interest of the user. The competition is bringing out the best of all competitors, and providing more and more features that help enrich the Web experience. The majority of Web sites today behave exactly the same on all Web browsers, and it is considered a design-flaw if a Web site does not work correctly on a certain browser. Tools are available to encourage (and sometimes enforce) using only the recognized Web-standards when designing a Web site. These standards have been vastly extended since the first browser war, and supporting non-standard elements is no longer an issue.

Grizzly 1.7.0

Source : http://blogs.sun.com/harshag/entry/grizzly_1_7_0_terminology

Grizzly 1.7.0 - Transport layer Details.

I've been working on integrating Grizzly transport into Glassfish ORB for quite some time now. Long since we were looking for ways and means to improve performance of CORBA request processing at the transport level in both Glassfish and JDK. That included connection management, parsing the messages, encoding and decoding messages etc. When we looked at current implementations in the open sourced field, we could not retrofit our requirements (from IIOP) into the existing frameworks. On top of this, we wanted a performance centric I/O framework. That brought up a new project called Grizzly with submodule framework using java.nio.

Here is a brief definition of Grizzly terminology:

Filter:

A filter is a component when placed in stream filters the stream. The interface tied to this is ProtocolFilter which has 2 methods execute() and postExecute() The filter can also be transformed into various forms based on the needs of the Grizzly framework user. For example, ParserProtocolFilter is designated to read certain number of available bytes from a given stream and then use a given parser implementation object to parse the read byte buffers.

Context:

A context is a place holder object to tell about the current state of event processing in Grizzly framework. Context gets to life at the beginning of selection cycle and ends in the callback handlers. Context has something called recycle() to recycle the state full information. All this happens in another interesting and important class called Controller.

Controller and Event Handling:

Controller is the one which does the very important event handling in Grizzly. Controller takes 2 approaches in handling NIO events. One is, through the callback handlers. And the other is, through filter chain. The filter chain gets executed sequentially until all the filters in the chain are (Chain of responsibility pattern) exhausted or until the current filter says to break the chain at the current instant. After this, all the filters' postExecute() method gets called in a reverse order to take certain appropriate actions while exiting the filter. Please remember that, the controller uses only one approach not both at any given time.

Callbackhandlers are very obvious from the code. The events it can handle are OP_READ, OP_WRITE, OP_CONNECT. Every time there is an event, the particular onRead(0 /onWrite() /onConnect() gets executed based on the type of the event. In order to accomplish this, one needs to first define a connector handler and callback handler. Controller uses something called SelectorHandlers and ConnectorHandlers to process events on the server side and the client side. Take a look at Controller code in Grizzly workspace for better understanding.

ConnectorHandler:

The Connector handler is the one that falls on the client side. It uses callback handlers to do the callback action based on the event types. That means, say, we are writing a client side implementation... in that we know where to contact server (host:port info.) once call to connect(..) is made, a connection is established. ConnectorHandler has specific methods to do reading and writing in both blocking and nonblocking modes.

SelectorHandler:

SelectorHandler basically runs in a separate thread. (can be configured according to onesneeds) and is a listener for a given channel. It handles / accepts events to handler new connection requests. The Controller is the guy which kicks in selector handler's selection cycle. Each selector handler upon selection,delegates the event handling like read, or write or connect with ContextTask (a thing to do) object and places the context task on a queue. Note that, ContextTask is a callable and hence gets called by a next available grizzly worker thread to do the task (callable). This is how each event is processed in Grizzly.

Pipeline (a thread pool):

Grizzly defines a default pool of threads and calls it a pipeline. Users can configure this pool implementation and it's very obvious from the code.

ProtocolChain:

ProtocolChain is a chain of filters. Can be used to read, write and parsingof a given stream from a channel.

--Harsha

-- Copied

Sharing is Caring