Communications Hub TF Minutes 2007-02-21
From MemberWiki
URL: /member/wiki/Communications_Hub_TF_Minutes_2007-02-21
Contents |
OpenAjax Alliance Communications Hub TF meeting minutes 2007-02-21
Attendees
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Ted Thibodeau <tthibodeau(at)openlinksw.com>
- Ric Smith <richard.allen.smith(at)oracle.com>
- Ted Goddard <ted.goddard(at)icesoft.com>
- Coach Wei <coach(at)nexaweb.com>
- Craig McClanahan <craig.mcclanahan(at)sun.com>
- Ken Tam <kentam(at)bea.com>
- Shel Finkelstein <shel.finkelstein(at)sap.com>
Original Agenda
- Agenda
- Joint meeting between Communications Hub TF and Server TF to review Greg Wilkin's proposals
Minutes
Jon/Coach: Couldn't get demo running
Coach: Jan 24 we discussed lots of items. In particular, what to achieve and what to deliver. Our consensus: (1) prototype of comm hub and recommendation to interop wg, (2) Greg's proposal as captured on wiki.
Coach: Since last conf call, waiting for Greg to commit so we can look at his prototype code. Today we will look at the code Greg has submitted.
Coach: Going forward, want to take a more detailed look at Greg's contribution. Need to get far enough before making a recommendation to interop group.
Shel: Like the idea of a reference implementation, but not as substitute for spec.
Coach: Now, we don't have a spec per se. Mission is to explore, not deliver spec or implementation. Just coming up with input to interop wg. Then interop wg will produce spec and code.
Jon: Greg did write a mini spec beforehand. We did work on use cases before that. Use cases around XHR in mashup scenarios and server push in mashup scenarios. Decided that server push was the key compelling feature because things don't work if you have too many push applications in same mashup. Overrun limit on number of connections. Then we talked about features and decided we needed APIs for both request/response and publish/subscribe (for push scenarios).
Coach: Problematic use case was push in these scenarios: (1) mashups, (2) multiple tab UI, (3) portlets or server-side mashups. In latter case, clearly there are server-side communications issues as well. Decided to focus on Ajax push for client and for server issues, decided we needed to work with Server TF, which led to this meeting.
Coach: With Greg's proposal, use a connection factory to get a connection. Then you can publish/subscribe to that connection. Straightforward API.
Coach: OK, that's the background. Now, let's look at the code contribution and decide on next steps. I sent a link to code in invitation.
Coach: Who has looked at code?
Jon/Coach: Yes.
Coach: Looks to me code is very simple. Most important file is OpenAjaxComm.js. Registers with Hub. By default, done via XHR. Greg also provided OpenAjaxCommsCometd.js. Using cometd instead of XHR. Shows ability to provide different connection factories. Also, provided test JS files and test example via HTML and Java servlet. Neither Jon nor I have been able to run the demo.
Jon: Nothing to add. I agree with you, Coach.
Coach: To do: (1) need to figure out how to run example. (2) At beginning, global var OpenAjaxComms registered. Should it be part of Hub or independent?
Jon: I was assuming we would just add the comm hub features as part of Hub 1.1, and thus not need any new library registration or new global vars.
Coach: That's what I was thinking, also.
Coach: So, maybe we should study code. Today, we have given a quick review to Server TF. Feedback from Server TF on how to collaborate?
Jon: Any instant reactions?
TebG: Good that Icesoft's server push would work in mashup scenarios. On server, we provide a custom factory for client. Maybe we wouldn't have to change what we have now on server.
Ric: Maybe we need a proxy server on server so not so many servlets. Looks like client side is doing a good job. Maybe an event servlet.
TedG: We could provide a reference implementation. Vendors could provide their own implementations.
Jon: Why would there need to be a proxy servlet? Why not just have client talk to [n] servlets?
Ric: Cross-domain hooks are usually on server.
Jon: Yes, but there are a couple of things in the works at W3C that might allow cross-domain on client. Also, browsers have some features in obscure parts of their UI already to allow user to allow cross-domain access to particular domains in particular cases.
(All) Don't want to prevent client-side multiplexing.
Ric: Jackbe has good multiplexing, centralizing on client side mainly. YOu are right that we need to allow client to do this. I was more trying to join multiple servlets together.
Jon: OK. You aren't proposing that people have to use the proxy server, just that it would be an attractive option for some scenarios.
Coach: What is Server TF looking at?
Ric: Looking at push. Looking at jMaki's features where there is a server-side hub of some sort.
Ric: Thinking that server proxy needs to take URL and translate into whatever server technology you have. An event mechanism.
Jon: Server TF also addressing the NxM problem by attempting to define standard APIs such that server frameworks all have to support only one way to load Ajax components and Ajax components only have to support one way to integrate the components into any server framework.
Coach: Java servlets built on req/response, not good for push.
Ric: A good approach is ActiveMQ from Apache. Uses JMS.
Coach: Nexaweb looked at it. My opinion is that this is not the best approach. For Web, need to go through HTTP.
Ric: Jeti offers continuation of connection.
TedG: Tomcat and others have alternate approaches. All different. JCP hasn't found the way to pull them together. What we heard is not being looked at yet in any group.
Coach: Yes, I would like to have plug&play of servlet engines, but not there now.
Ric: Really a JCP issue, but what role can OpenAjax play?
Jon: Remember that we are independent of Java. Maybe OpenAjax can define something that works with Java, PHP, and .NET.
Ric: Yes, lobby the community to implement.
Jon: What is model for proxy server?
Ric: URL pattern. Payload as json or xml. Then translate into server technology. jmaki is doing this.
TedG: What if no translation is required? Just pass through?
Ric: Yes, just pass through the body.
Jon: Who triggers events?
Ric: Starts off with HTTP request. Then route. Server process responds and that's another event. In most cases, this is all asynch.
Jon/Ric/TedG: Maybe we define a spec for messaging on server side. Leave it to vendors to implement. (But we would have a reference implementation)
Craig: I sent a change to POM to get the example to work. I sent email to the group.
Craig: We would define mesage formats and one or two reference implementations. On server side, define a message format with a header, then topic, then payload. Route to people interested in the topic. Maybe xml.
Jon: All within payload of HTTP request?
Craig: Yes.
Jon: Independent of communication protocols and server frameworks! That's good.
Shel: Maybe wrap at the top saying the payload is multiplexed.
Ric: With ADF, we collect messages together to handle multiplexing.
Jon: Maybe GregW is already doing this within his code. Coach, do you understand the encode/decode part of GregW's code?
Coach: This is about encoding for different HTTP parameters, such as form encoding.
Coach: OK, wrap it. Next call in two weeks for communications task force. Server TF people definitely invited.
