Communications Hub TF Minutes 2007-04-26
From MemberWiki
Contents |
OpenAjax Alliance Communications Hub TF meeting minutes 2007-04-26
Attendees
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Ted Goddard <ted.goddard(at)icesoft.com>
- Coach Wei <coach(at)nexaweb.com>
- Craig from Sun<Craig.McClanahan@Sun.COM>
- Mark Phillips <M8PHILLI(at)uk.ibm.com>
- Ted Thibodeau <tthibodeau(at)openlinksw.com>
- Steve Hunt <steve.hunt(at)coradiant.com>
- Greg Wilkins <gregw(at)webtide.com>
Agenda
- 1. Identify scribe
- 2. Review last conference call's action items:
- Ted: create a proposal for a simpler way to address server side communication issues;
- Ric: to connect with Joe Walker to see whether he has materials around communications related problems etc. and use as feedback to the TF;
- Coach: to use Ric/Joe and Greg Wilkin's input to create an initial draft of problem definition for discussion.
- 3. Discuss Problem Definitions
- While thinking of problem definitions, I realized Greg Wilkin's earlier input: /member/wiki/Interoperability_Communication is a good start. It outlines 4 problematic use cases - Are there other use cases? What do people think of these four use cases?
- 4. Wrap up
Minutes
- Scribe: gregw
- ted: has a draft for simple comms notification mechanism
- single URL push/notify
- POST to get notifications
- 2 connection limit main issue addressed
- aims to share notification channel.
- client gets the message itself
- form encoded... no xml or json
- session ID? at path /
- multi windows deal with session ID
- gregw: suggests browser ID name instead of session ID
- jon: is this for mashups?
- ted: only when mashups are on same server.
- coach: there are multiple issues that we should consider. This proposal deals with two connection limit
- gregw: I think the notification proposal has problems with efficiency. a second request is needed to fetch the data and multiple components may mean multiple requests. Do we loose the ability to address other issues with this
- ted: the protocol could be extended to included message transport
- gregw: so we should think of this as a minimal requirement for a protocol?
- coach: let's increased scope...need to define problems we need to solve. Do we agree to the use-cases outlined in Greg's original document: /member/wiki/Interoperability_Communication#Problematic_Use-Cases
- jon: looking for requirements for solutions as well as issues to fix
- coach: reviews 4 use cases
- 1) is just the 2 connection limit
- gregw: yes but as it applies to multi frameworks on same page. 2) is the limit applied to multi tabs. Same problem but different use cases and it is possible to solve one without the other.
- 2) multi tab/windows
- 3) server side mashup URL clash
- 4) communications efficiency
- ted: multi tab.. can't be efficient. But notification method can be used and can be done over cookies.
- gregw: bayeux uses advice and fall back to traditional polling for multiple tabs
- jon(or coach?):can we solve multi tab issue?
- ted and greg: say yes we can and it is important to do so
- ted: icefaces uses notification + payload so is moderately efficient and solvable.
- gregw: should hub have inter window notifications that the communication solution can use to implement this solution
- jon: no technical reason or security reason why not
- coach: drag item from one window to another is a use case for it
- jon: tibco light streamer push may already show it?
- coach: I don't think so
- Greg drops out of call
- talk about use-case 3
- in-band vs out-of-band comms. Ajax that uses in-band comms is going to have trouble with portlets and server side mashups
- coach: concern that out-of-band comms may bypass portal servers provided services.
- general agreement that all 4 use cases are important and should be addressed by the task force.
- greg suggests user awareness issue.
- next meeting in 3 weeks
- javaone get together? tuesday dinner!
Action Items
- coach: improved statement of issues to be addressed by task force.
- gregw: help coach with above.
