Coach Wei's comments on November 9 2006
From MemberWiki
In this short writeup, I am trying to answer the following questions:
- What are the problems we want to solve (and what are the problems we do not want to solve)?
- What is my proposal to the task force?
Greg did a great job on Interoperability Communication. He outlined four uses cases (or four problems associated with communications):
- 1. Ajax Push framework interoperability
- scenario: two or more Ajax Push frameworks within a single Ajax client application.
- issue: Each frameworks initiates a long poll and consumes the browsers per host connection limit.
- 2. Ajax Push multi tab/window usability
- scenario: An Ajax Push based application is opened in two or more tabs/windows of the same browser.
- issue: Each instance of the application is unaware of the others, initiates its own long poll and thus consumes the browsers per host connection limit.
- 3. Server side Ajax component interoperability
- scenario: An server uses portlets or server side mashups to combine multiple Ajax components into a single page/application.
- issue: The client side components will be unaware that the page URL is shared by other components and frameworks and may attempt to use the source URL to communicate with their server-side components. The portlet or mashup will not be able to differentiate requests targetted as component to component communications vs requests to refresh the entire page.
- 4. Service side Ajax component efficiency
- scenario: An Ajax application that is composed of multiple components with server side elements.
- issue: Some event on the client side may cause all those components to attempt to refresh their state from the server side, so multiple requests to the server will be made and significant latency may be experience.
What Are the Problems that We Should Try to Solve?
My proposal is to solve problem 1 and problem 2. We will not solve problem 3 and problem 4.
My reasons are:
- Problem 1 and 2 are within our scope and seem to fit "lower hanging fruits" criteria;
- Problem 3 and 4 seems to be outside of this TF's scope. For example, maybe better addressed by Server TF;
Gregw response: I don't see each scenario requiring a different solution. By solving 1 and 2 we are very likely to solve 3 as we will not be using in-band communication. Issue 4 can be solved if the solution for 1 and 2 supports batching. Thus I think 1 and 2 are our main drivers, but we should evaluate all proposals against all use-cases.
My Proposal to the Task Force
- The Scope of our Task Force:
- Address Problem 1 and Problem 2;
- Share or pass Problem 3 and 4 to Server TF;
- Proposal to Interop Committee from this Task Force
- Work with Marketing Committee to:
- Lobby browser vendors to provide more connections
- Work with Marketing Committee to:
Gregw response - I am very cautious about this as it will just stress the servers even more. If we do a reasonable job of providing a messaging tier, then more connections should not be required. Although there is an argument for 2 connections PER DOCUMENT per host that will resolve the multi tab issues somewhat
- Develop code to be included in the initial OpenAjax Hub to address problem 1 and 2
- In the form of a small cient library
- The small client library is required by an OAA-compliant toolkit to use in order to open a long poll or server push connection (the toolkit should call this hub to create an instance of XmlHttpRequest-like object for communications)
- The small client library would provide an XmlHttpRequest like interface
- Develop code to be included in the initial OpenAjax Hub to address problem 1 and 2
- I have completely left out anything related to security, XSS and so on. have not studied enough to form an oppinion with regard to comments or proposal.
