Interoperability Minutes 2009-02-16
From MemberWiki
URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-02-16
Attendess
- Jon Ferraiolo, IBM
- Matthias Hertel
- Javier Pedemonte, IBM
- Howard Weingram, TIBCO
- Kris Vishwanathan, IBM
Minutes
(Stepping through the red-colored notes in the following wiki page)
http://www.openajax.org/member/wiki/OpenAjax_Hub_1.1_Specification_Managed_Hub_APIs
Jon: Have all of the email conversations been captured in red-colored comments on the wiki?
Howard: I believe so
Jon: I'll go through the emails during the past week and verify, but after this phone call.
Callbacks: editorial approach
Jon: There isn't a standard template for documenting callbacks. For example, some callbacks use made-up classes, such as OpenAjax.hub.ContainerCallbacks.onSecurityAlert. Can we just remove the made-up class names?
Howard: I'm fine with that.
Jon: I'll send a proposal for how to document callbacks
ACTION: Jon to send proposal on how to document callbacks
OpenAjax.hub.log
Howard: I see that I have some typos. I'll clean that up.
Howard: But what do people think of this feature?
Javier: What's it for?
Howard: Matthias expressed a need to do logging when we had the discussion about removing onWarning. console.log isn't available on all browsers. IDEs might want to intercept log messages and post them elsewhere. Most of the log messages are expected from Containers and HubClients. My proposal is to be as simple as possible. No log levels, for example. Just a string.
Jon: I'm favorable
Kris: What's in the message?
Howard: Any string that you want to log. If you want to indicate that the message is coming from a container, we could do that.
Jon: I suggest we mkae is mappable to console.log.
Howard: Yes. Developers could insert their own function. So, OK to leave it as a string.
Kris: Yes
Howard: Most of the time this is for displaying log string messages
Javier: Looks fine
Jon: So, you have added a log parameter wherever there used to be an onWarning parameter?
Howard: Yes, pretty much.
Howard: I'll fix the spec
RESOLUTION: Accept OpenAjax.hub.log as proposed
ACTION: Howard to update the spec in this area
managerSubID in subscribeForClient and unsubscribeForClient
Jon: Everyone seemed to be OK with this proposal on email. Looks fine to me. Any objections?
Javier: One more thing. Do we need a clientSubID?
(Howard responds about how this change was necessary and high-volume)
Javier: I'm fine with that
RESOLUTION: Accept managerSubID
ACTION: Howard to update the spec in this area
OpenAjax.hub.Container - protected class, interface, or what
Jon: I attempted to add a sentence that described the behavior to achieve "protected"
Howard: Should say properties and methods instead of services. Let me take a look at it. I've taken out some of the private features. Just a couple left.
Javier: Container still stores a couple of things, hub, id, ...
Howard: We have getters for those. If we had getters for everything, then we wouldn't need protected. But there is onConnect and onDisconnect...
Javier: Should we allow direct property acccess or require the use of getters?
Howard: Getters emphasize things are readonly
Jon: Whatever, we need to make sure that containers can be portable across different implementations of the Hub. Therefore, containers should only use APIs that the spec defines as public.
Javier: Could also make OpenAjax.hub.Container into an interface. Not that much shared code these days between the base class and derived classes.
Howard: Yes, make it an interface
Howard: Note that we'll need to document clearly what each container must do.
Matthias: That's fine.
RESOLUTION: OpenAjax.hub.Container will be an interface
ACTION: Howard to update the spec in this area
New exceptions on OpenAjax.hub.Container
Howard: I added some exceptions that bubble from ManagedHub to Container. (Describes an alternate approach)
Javier/Howard: (agreement on approach where container is required to call ManagedHub.addContainer()
Jon: OK
Howard: I'll add appropriate notes about requirements to the spec
RESOLUTION: Accept new exceptions and say that container must call ManagedHub.addContainer()
ACTION: Howard to update the spec in this area
Documenting params params using JSDoc
Howard: I'll take a quick pass to merge the JSDoc comments from the source code into the wiki and clean up the params params to match the JSDoc spec recommendations
Howard: My proposal for how to update the spec: First change the open source JSDoc comments, then immediately copy into the wiki. Therefore, people shouldn't change the JSDoc comments on the wiki directly, but OK to include notes on the wiki page around the JSDoc comments
Jon: Which JSDoc spec?
Javier: jsdoc-toolkit on google code
RESOLUTION: Accept Howard's proposals on params and how to update the JSDoc blocks on the wiki
ACTION: Howard to merge JSDoc comments from the source code onto the wiki page
ACTION: Jon to verify with Phil Berkland that param params approach is ok
Exception types
(discussion/agreement that an exception can be any JavaScript class)
ACTION: Jon to ask IDE group about whether OK to use non-errors for exception types
Note about onConnect should not be called if disconnected
Howard: Spec doesn't prevent this. We just tell developers they can't count on this, etc. More of a best practice. Doesn't belong here. Leave it in the best practices chapter.
OpenAjax.hub.Container.prototype.remove
Jon: Javier added text about how containers need to unsubscribe from any of their existing subscriptions
Howard: Yes, that's good
getOnSecurityAlert() and getLog()
Howard: May be unnecessary now now that Container is an interface. I'll take care of that.
ACTION: Howard to remove these
iFrameContainer extra params: uri, tunnelURI, parent
Jon: What did we decide last week?
Howard: We agreed on uri and parent, but for tunnelURI, it is required only for FIM
(no objections)
ACTION: Howard to update the spec in this area
HubClient.connect (and disconnect)
Javier: This comment is old. I have already updated the code. We can remove it.
Howard: I'll clean this up.
ACTION: Howard to update the spec in this area
IframeContainer constructor and verification of HubClient
Howard: That's an implementation requirement. Belongs in the container chapter. I'll fix the spec.
ACTION: Howard to update the spec in this area
InlineContainer constructor and verification of HubClient
Howard: In email, we decided that passing a hubclient id was good. I'll fix the spec.
ACTION: Howard to update the spec in this area
InlineHubClient constructor
Howard: These new items probably belong in the chapter on creating things, not here.
Jon: Informative notes?
Howard: Yes.
ACTION: Howard to update the spec in this area
