Communications Hub TF Minutes 2007-03-14

From MemberWiki

Jump to: navigation, search

URL: /member/wiki/Communications_Hub_TF_Minutes_2007-03-14

Contents

OpenAjax Alliance Communications Hub TF meeting minutes 2007-03-14

Attendees

  • Jon Ferraiolo <jferrai(at)us.ibm.com>
  • Ted Thibodeau <tthibodeau(at)openlinksw.com>
  • Ted Goddard <ted.goddard(at)icesoft.com>
  • Coach Wei <coach(at)nexaweb.com>
  • Ken Tam <kentam(at)bea.com>
  • Alex Russell <alex(at)dojotoolkit.org>
  • Greg Wilkins <gregw(at)webtide.com>
  • Stas Malyshev <stas(at)zend.com>

Original Agenda

Minutes

Coach: Lots of good email discussion lately. Given upcoming F2F, worthwhile to talk about some items. First, Jon's proposal of March 7 suggesting a reorganization of task forces going forward. Basic idea goes as follows. Now there are 3 task forces: server, communications and ide. Break server into two parts. One part joins the ide tf to work on metadata for IDEs and server frameworks. Second part consolidates the server communications efforts with the client communications hub into a single communications working group. Makes a lot of sense. Obviously, need to coordinate these two communications efforts. What do people think? Obviously lots more discussion is needed in the next few weeks and need to follow the Development Process.

TedG: Only natural to merge.

(no other comments)

Coach: OK. Discuss this some more at the F2F meeting.

Jon: We need to talk a bit deeper than just working on communications, both client and server. I see 5 pieces. (1) Client APIs. (2) Client open source implementation. (3) Server APIs. (4) Server open source implementation. (5) Communications protocol(s) between client and server, where Greg and others suggest that we would work on a default communications protocol but allow other protocols be used to address specific requirements and allow for innovation. I am assuming that our default communications protocol would be a subset of Bayeux since that looks like a good effort led by the right people.

Alex: Bayeux isn't done yet. Trying to work through a complete spec of 1.0 by April 15.

Jon: I think having a standard/default protocol is important to enabling industry interoperability, which is key to achieving widespread adoption.

Greg: Yes, but difficult to agree on a protocol. There will be lots of people who complain about anything that is proposed. Lots of technical work behind it, also, including clustering, security and extensions.

TedG: Good to leverage HTTP for security.

Greg/Alex: Will be using HTTP almost always. But there is need for innovation around security.

Jon: I'm looking for feedback on two proposals. (1) We need to define a subset of Bayeux that can be established as a long-lived standard, (2) We work on that subset at OpenAjax. Comments?

Greg/Alex: Don't do any OpenAjax protocol standards until early prototypes are working and specification is proven in practice.

Greg: OpenAjax should start work at first on things other than the messaging protocol at first, particularly APIs. In future as Bayeux and implementations progress, decide what to do about messaging protocols.

Coach: I see OpenAjax clearly working on client-side issues but not sure about server-side.

Greg: I believe API should be open to other protocols and multiple server technologies. My current client proposals work with existing servers. But if we define good server APIs, we can enable the industry to achieve more. If you implement our optional server-side hub, you have ability to implement more efficient server. Plus there will be extension points for further innovation and improvements.

Jon: What do you mean by "optional" in optional server-side hub?

Greg: Our APIs should define some server-side semantics. These semantics can be implemented via the server-side Hub we provide or map to multiple different server side components.

Jon: So, sounds like we focus on client side features (my (1) and (2)) first while more loosely participating and monitoring work in Comet community on server-side implementations (my (4)) and messaging protocol (my (5)).

Coach: Agree. But we will discuss this more at F2F. How about what things should be pursued by OpenAjax and what things by other organizations.

Ted/Coach: Nothing in OpenAjax charter prevents us from doing things beyond the client.

Greg: I think we need a lot more rigor behind reviewing the client-side proposals.

Jon: I think we need to work on client, server, and messaging in coordination to make sure we have a full solution that holds together.

Greg: Yes, at least server prototypes to test against the client technologies.

Ted: Does OpenAjax have a process for verifying that specs have 2 implementations?

Jon: No formal process for that. Do whatever makes sense. But definitely we want the result to reflect something like that.

Greg: For protocol, maybe better as an IETF standard.

Ted: If IETF, need to set up a working group there. And they won't like doing things that go against HTTP spec.

Greg: Only submit features that don't conflict. Other things would be extensions.

Alex: Another approach is that OpenAjax does preliminary spec work before handing off to IETF.

(various people express agreement)

Greg: What about OpenAjax prototypes of APIs, with Dojo doing Bayeux work for time being? Down the road, OpenAjax can look at how things ended up with Bayeux and decide about working on a subset of Bayeux or looking at an alternative?

Alex: At Dojo, we are working on the Bayeux protocol now. Later we will decide what to do about standardization of that protocol.

Jon: Greg's proposal is fine with me.

Greg: What activities are we doing to validate the proposals?

Coach: Let's go back to mission of task force. We are here to find justification for forming a working group, which then will pursue a solution. We don't need to go all the way to a solution within the task force stage. I think we can form a working group to take over from the task force.

Greg: But before going to a working group, we need more representation from industry. More people looking at our ideas and saying the approaches are something they can work with.

TedG: Good to get indication of companies who would integrate the technology.

Coach: Need to make a proposal in order to get feedback.

Coach/Jon: Need to start a proposal for a work activity, not yet a proposal for a working group.

Coach: We could post the proposal at the OpenAjax web site and wait a couple of weeks for feedback. Then maybe start a working group or maybe roll into an existing working group.

TedG: Vital to gather feedback from other organizations.

Jon: Who will work on the proposals? Best to have proposals in time for face-to-face next week.

Greg: I can adapt existing proposals. I will commit having proposals ready by end of the weekend. But technical, not procedural.

Coach: I will be able to help.

Jon: Next Thursday is the discussion day.

Coach: Let's skip the agenda item on server apis for now. Any other topics?

Jon: How about Ted's email from earlier today?

TedG: Basically two things. As an alternative to a full protocol, take a simpler route. Easier to specify, but at expense of some runtime efficiency. (1) Have ability to tell client when channel has an outstanding message. A notice of messages that are pending. Then client can retrieve the message via usual mechanisms. (2) Form discussions with Craig, offer a tunnelling over a blocking request so multiple responses can be issues to many clients. But need a container format such as XML or JSON.

Jon/Alex: Bayeux can hold multiple messages.

TedG: But Bayeux is much more complex.

Greg: I think that if we wanted a lightweight approach, this would be easier to standardize. And implementations could extend it to make it faster. Yes, should look at this as a candidate along with Bayeux.

Coach: I didn't understand how client gets notification

TedG: Blocking HTTP or long polling

Alex: Blocking is a poor choice

TedG: If protocol is simple, different approaches can be used for different communications mechanisms

Alex: With Bayeux, the message is independent of the transport. Only define the format of the information.

Coach: What is value given that clients can always poll?

TedG: Centralize handling requests of server connections. Distill all down into one server request.

Coach: Basically solving client-side interop

Coach: OK, let's continue discussion at F2F

TedG: Can we call into F2F?

Jon: Yes. Number is posted on wiki page for meeting. Communications will be discussed Thursday afternoon.

Retrieved from "/member/wiki/Communications_Hub_TF_Minutes_2007-03-14"