Communications Hub TF Minutes 2007-06-06
From MemberWiki
Contents |
OpenAjax CommunicationHub
2007.06.06 Minutes Taken by Howard Weingram
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 (re use case #1) @@ Howard: provide more info re JSR 286 (for use case #3)
Attendees:
- Ric Smith- ORCL
- Coach Wei - Nexaweb
- Serge - Zend
- Ted Goddard = IceSoft
- Jon Feraiolo - IBM
- Ted Thibodeau - OpenLink
- Mark Philips - IBM
- Howard Weingram - TIBCO
Overall Goal: Review Problem Definition for the Task Force
Input:
* Greg's proposal * Alex says they have done an implementation. It's "ugly". * Issue: sending large messages between frames * Issue: portability & reliability
Problem Definition (Coach):
1. Combining client side Ajax push frameworks
Challenge: avoid exhausting the 2-conn limit
2. Two different tabs, where each has own push connection
Challenge: avoid exhausting the 2-conn limit
3. Server side Ajax comm. interoperability
Challenge: client-side components in portlets may attempt to use the source URL to communicate with their server side components. Server must be able to differentiate between requests to refresh the page and requests targeted at one portlet or component
4. Comm efficiency
Challenge: do batch processing so client not sending lots of small requests
5. Cross site communication
See below
Some Requirements for the Solution:
1. Provide way to give user feedback of something going on over network
Callback mechanism for connection status/issues, or query mechanism.
Make sure API is informative enough for app to pick up this info.
Solution Concept:
A consistent, general idea of portable reusable messaging API
Discussion of Use Cases
Use Case #1.
Combining client side Ajax push frameworks without exhausting 2-conn limit
Proposals:
* Greg's proposal
Jon: OpenAjax.com.bridge(topic, ok2Forward) defines when a published event should be forwarded outside of current browser frame, especially other frame or web site.
Jon: e.g. chat session: myapp.chat might be topic. Whenever someone types something, pass myapp.chat & flag to say it's okay to forward. This notifies the hub that it is okay to forward outside of current context.
Coach: also a provider mechanism. Plug in a provider that provides specific impl for the communication API. Send to frames on same instance? send to server?
Coach: also toolkit provider can impl provider & plug into com hub to do the actual communication
Jon: needs to be mechanism to marshal across a boundary.
Jon: works with with Ted's proposal; orthogonal. Ted was describing protocol. Greg isn't. Coach: works well with current oah architecture. Utilizes OAH.
Jon: good starting point for discussion but must be fleshed out.
Jon's email questions: does it have optimal approach toward generalizing marshalling? Boolean flag to marshal to frames & web sites; Generalize notion of frame to module? Offline, google gears.
Jon: need to change footprint of callback function?
Jon: need to add more features to marshalling capability? 2 flags (marshal to web sites, to frames) Filter function to decide on particular web sites/frames? Use wildcard names to decide what gets marshalled?
Howard: security zones and topic names as part of the interface between zones
@@ HOWARD write some thing up in this area
* Ted's proposal
Protocol oriented
Use Case #5.
Cross site communication
Coach: Should we add this?
Jon: need to address cross-site issue. Industry is moving forward. OAA needs to be ready.
?: Some want ability to create mashups. Some want to guarantee that they are impossible. Non-interference between widgets / toolkits that coexist.
Jon: host apps in different toolkits on same domain. OAH addresses.
Jon: but OAH doesn't address case where iframe on page is talking to other domain, & no comm is possible. OAA needs to address that somehow - maybe by promoting an approach. Browser vendors control this. Hacks like dojo iframe proxy hack can help but advocacy is probably the main thing to do on the client side.
Coach: what is dojo iframe proxy hack?
Jon: browsers allow you to change URL string on src attribute for iframe after the # mark - the frag identifier & it won't go refresh the iframe content. Parent & child can pass data that way. Accidental probably. Would still need to add logic to marshall events between parent and child.
Howard: issues with that include message size limits, update trigger. Gideon mentioned resize in NYC, but it's not clear whether that ports. Dojo uses timers.
Coach: which TF addresses this? Seceurity?
?: maybe no security TF; everything you do has sec considerations. Borrow people from sec group if you need to.
Jon: Sec Task Force can do documentation & evangelism with browser vendors. Future oriented stuff.
?: Security considerations to everything. This comms group needs to deal with this one.
Coach: assume both child and parent implement OAH, what are the issues?
Jon/Howard: if different domain, child page in iframe can't invoke parent functions & vice versa.
?: if we do find a way around this we must be careful to allow it to be disabled
Howard: don't want logic passed between frames & executed without inspection
?: don't allow every piece of info to be sent from parent to child iframe / vice versa between domains
?: should be able to allow and forbid cross-domain communication
Coach: isn't that app developer's responsibility?
Howard: yes but comm hub must empower developer to make the decision
Coach: need to propose wording for use case; sensitive topic. May not need
Howard: we should include a 5th use case. May not actually implement.
Jon: make sure the language says that so that people aren't confused.
@@ COACH: add 5th use case: propose initial wording
