From MemberWiki

Contents 1 Attendees 1.1 Agenda 2 Minutes 2.1 Action Items

Attendees

• Jon Ferraiolo <jferrai(at)us.ibm.com>
• Ted Goddard <ted.goddard(at)icesoft.com>
• Coach Wei <coach(at)nexaweb.com>
• Rick Smith (Oracle)
• Stas Malyshev <stas(at)zend.com>
• Greg Wilkin
• Howard Weingram

Agenda

• 1. Identify scribe
• 2. Review last call's action items:
  • Coach: write up the 5th use case & propose language
  • Coach: Start a requirements document / page for solution/s
  • Howard: propose something re security zones and restricting interfaces between them (reuse case #1)
  • Howard: provide more info re JSR 286 (for use case #3)

• 3. Discuss and finalize Problem Definitions
  • A draft Problem definition: /member/wiki/Problem_Defintion_-_CommunicationHub is here. This has been updated with a 5th use case per June 6 2007 conference call.

• 4. Discuss Requirement Document
  • A draft Requirement document is here: CommunicationHub_Requirements.
• 5. Discuss proposals:
  • Communication API Proposal
  • Communications Events Proposal
  • simple protocol for Ajax Push

• 5. Wrap up

Minutes

coach: any feedback on the 5th use case?

Jon: Greg's proposal for component-to-component communcation API is interesting. Greg's bridge mechanism enables broadcasting capability - we need to offer additional APIs for point to point communications, etc.

Howard: I have done something like this before and can prospose something here.

Jon: can you write up something to describe it?

Howard: ok.

Howard: We should allow people to use different providers;

Ted: cross document messaging from WHAT working group using JavaScript is interesting.

Jon: if we adopt such API, it will be ideal. Future browsers may implement this too.

Ted: I've already signed up for their mailing list.

Howard: it is better to take a look at their documents first and decide what to do.

Jon: WHAT is not supported by Microsoft;

Howard: we need to provide something that acts as abstraction, without relying on browsers.

Coach: i also wrote a requirement document draft - any thought/feedback?

Howard: with regard to the two action items, i haven't got a chance to look at them yet, but hopefully some time this week.

Coach: We have three proposals now: API, Events and Protocol. What do people think?

Ted: I like it most is to resue the OpenAjaxHub for API. The protocol proposal i am working on is to be enhanced. Last time we talked about it, we were concerned about efficiency. Now i am enhancing it so that some messages can be delivered as part of the notification.

Coach: what kind of messages will be delivered and what won't be?

Ted: if we have an efficient cross-frame mechanism, then we can deliver all messages over the wire; If not efficient, then only deliver some of the messages.

Coach: why is this related to cross frame communication?

Ted: because in multi-frame scenarios, there is only one push connection allowed. So they need to communicate.

Coach: the subspace proposal seems to solve the problem well.

Ted: if the user opens a new window, there won't be parent/child relationship. If you don't have parent/child relationship, there won't be able to share Javascript objects.

Howard: if the frames are not from the same domain, there is very little you can do.

Ted: i am talking about frames coming from the same domain - but there is no parent/child relationship.

Howard: you can get the "opener" in this case.

Ted: My take is that "subSpace" is good for cross-domain, parent/child situations, but not good for those situations that parent/child relationship doesn't exist.

Greg: my concern is that it creates server scalability issue - because it may encourage more server connections that is very expensive.

Coach: if communicationhub is used within these iframes, we can make sure that they share a common connection.

Greg: but there is an initial hit with each iframe loading its own content;

Howard: setting document domain also has problems on firefox.

Greg: for Byuex, we just use the parent frame communicationhub object directly.

Jon: but you won't be able to acccess parent frame if they are on different domains.

Coach: the next few weeks we'll spend most of our time talkinga bout the API, event and protocol proposals. What do people think?

Greg: now i hate the API proposal - like the events proposal much better.

Coach: are you recommending we replace the API proposal with the events proposal?

Greg: yes.

Ted: what about batching?

Greg: good point. Maybe we can add batching to the brigde API?

Jon: the API proposal also has a "provider" mechanism.

Greg: the pub/sub API users will not be concerned about providers, which is a job of the page composers.

Jon: we still need soem documented ways for providers to plug in.

Coach: Greg, can you add point to point, batching, and provider mechanism to the document?

Greg: i'll add batching and provider to it. Not sure of point to point.

Howard: i'll make a proposal on point to point on the existing pub/sub system.

Action Items

Greg: add batch processing and provider mechanism to the Events proposal;

Howard: make a proposal on point to point communication.