Interoperability Minutes 2009-01-26
From MemberWiki
URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-01-26
Attendess
- Jon Ferraiolo, IBM
- Matthias Hertel
- Javier Pedemonte, IBM
- Kin Blas, Adobe
- Howard Weingram, TIBCO
- Rama Gurram, SAP
- Eduardo Abe, ILOG/IBM
Original agenda
- Agenda
- Discuss new pictures at top of Managed Hub Overview chapter
- Walk though red-colored open issues in Managed Hub API chapter
Minutes
Overview pictures at top of Managed Hub Overview chapter
Javier: Pictures look fine to me, but maybe remove "one instance for each app"
Matthias: Any problems if we allow only one?
Howard: Designed to allow for multiple managed hubs. I guess it's OK to leave in the comment about just one instance. Otherwise, asterisk make it look like normally there would be multiple.
Jon: Could remove from the picture and move the comment to the text.
Javier: That would be better.
Jon: OK
Howard: Addition of OpenAjax Hub is confusing.
Kin: I have a question about the entire document. Meant as an overview of how things work? Seems a bit confusing. But I don't see much text about what each piece does.
Rama: I agree. Need to be clear.
Howard: There is text in between the two pictures. Needs to say what each one does.
Jon: I agree. You are right. Needs more text.
Howard: I prefer the original diagram to this one. This one doesn't show which is on the client side and which is on the manager side. Also, it looks more complicated.
Kin: One more question. Does Managed Hub contain the OpenAjax Hub?
Jon: No
Kin: OK
Kin: I like Howard's diagram better.
RESOLUTION: Revert back to previous drawings (Howard's). Replace blue text at bottom with two halves with a gutter in between
Hub APIs: OpenAjax.hub.SecurityAlert
(Discussion about "(2009-01-26 JON) ISSUE: There was email between Javier and Howard about security alerts. We should discuss and make sure we capture anything that needs to be added to the spec.")
Jon: Just making sure. Was this email discussion only about how things are implemented in our open source? Are there any aspects that need to be captured in the spec?
Javier: Nothing needed in the spec
RESOLUTION: Can remove this issue
Hub APIs: OpenAjax.hub.SecurityAlert
(Discussion about "(2009-01-26 JON): subscribe() parameter reordering" - which exact parameter order should we use?)
Howard: Shouldn't subscriberData be before onComplete?
Matthias: I vote to make as compatible as possible with Unmanaged Hub for the most popular parameters, which are the first 3
Howard: What if people were using subscriberData? We've used subscriberData ourselves. Convenient for closures and things.
Javier: I like the way it is now.
RESOLUTION: Keep the parameter order as is in the spec now
Hub APIs: wording about async
(Discussion about "(2009-01-26 JON): async processing - Email discussion about whether events are asynchronous. Howard says iframes are async but inline is sync (in fact, before publish() is completed). Proposal is to say that timing of when callbacks occur is undetermined and components need to be aware that callback might be either async or, due to JS single-threaded, might happen synchronously within nested logic")
Howard: Inline may be implemented synchronously. IFrames always asynchronously.
Jon: (reads issue verbatim)
Howard/Matthias/Javier: Yes
Howard: Might include further elaboration about before publish completion. Callbacks might be called, disconnect or whatever. State of the app may change during publish.
Matthias: Two subsequent messages can't return before first publish function.
Howard: Could reuqire that implementations deliver messages in a particular order. I'll think about this and send email.
Jon: Needs to say something about how clients MUST not rely on a particular timing or order, as we said in Hub 1.0 spec, but Hub implementations SHOULD deliver messages in a particular order as described in the spec.
RESOLUTION: As the issue text expresses things, but Howard will propose additional language about ordering.
Hub APIs: data type of {*}
(Discussion of issue about how to document "data {*}" on publish())
Howard/Jon: Change {*} to {Object}, with comments that it must be JSON-serializable.
Hub APIs: @return in publish()
RESOLUTION: Yes, remove the @return on publish()
Hub APIs: safeDelete and safeCall
Howard: Can get rid of safeDelete
Javier: I looked through the code. safeCall is only used in conjunction with safeDelete. Why do we need safeCall?
Howard/Javier: Yes, can rely on garbage collection
RESOLUTION: Remove both safeCall and safeDelete
Hub APIs: Distinguishing between OAH parameters and container-specific parameters
(Review Howard's list of 3 options:
- Separate parameters for OAH standard and Container-type-specific params
objects, OR
- params object must include a separate sub-object that holds
Container-type-specific parameters, OR
- Container params should have some distinguished prefix.
)
(Everyone prefers a variable of #2)
Jon: Should we prefix the standard parameters with oah.?
Howard: Our stuff in subobject would be a good example to container developers
Jon: With a note that says "you should put your parameters into your own subobject"
Jon: What about oah.?
Howard: OpenAjax.? ManagedHub.? Container.?
Jon: You are saying params would have a subobject named OpenAjax or ManagedHub or Container?
Howard/Javier: This is used mostly for containers. Leave alone for the Managed Hub. Won't be many differences in implementations of the MH, but more likely for containers.
Howard: I suggest Container. and HubClient for our parameters. Allows for iFrameContainer. and FooBarContainer., etc.
Jon: Sounds good to me. Any objections?
(no objections)
RESOLUTION: No subobject for ManagedHub paramters. Use subobject Container for our container parameters and HubClient for our HubClient parameters.
Hub APIs: parameters as readonly
RESOLUTION: Need to capture and put into the spec the email discussion about OAH params being read-only
Hub APIs: subscriptionID versus subscriptionHandle
Jon: Same thing?
Javier: From user perspective, yes, but implementation has two different things. Container has its own list of subscriptions (subscriptionID) and ManagedHub has its own list (subscriptionHandle).
Howard: We should return @return subscriptionHandle.
Howard: unsubscribeForClient now takes container and subscriptionID
RESOLUTION: As Howard says above.
Hub APIs: subscriptionID opaque?
RESOLUTION: Yes
HubClient instantiation
(Discussion about how the HubClient interface is made available to the Client Application)
Howard: An iframe has to have a URL that points to a server. That page knows it is dealing with an IFrame URL. Therefore, that piece of infrastructure (outside of the spec) would have to instantiate the HubClient. The Manager Application has to instantiante inline HubClient. Again, implementation-specific and outside of the spec. Part of the application framework and not in the standard.
Jon: Makes the HubClient object available?
Javier: Application framework has to instantiate the HubClient
Jon: What does Client Application have to do?
Howard: Inside of sandbox, needs to instantiate a HubClient wiht parameters and call connect()
Jon: OK, thanks.
Howard: For clarity, talk about what needs to happen for things inside the sandbox.
RESOLUTION: Yes, we need to include IFrameHubClient and InlineHubClient objects on this page. Only need to document the constructors.
Howard: Maybe also getters and setters for the parameters. I'll get back to you on that. onSecurityAlert, onWarning, scope.
Howard: Also, framework parameters. For example, tunnel URL.
Javier: Why would we want that?
Howard: Probably don't.
RESOLUTION: Don't need the getters.
