Interoperability Minutes 2009-02-02
From MemberWiki
URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-02-02
Attendess
- Jon Ferraiolo, IBM
- Matthias Hertel
- Javier Pedemonte, IBM
- Kin Blas, Adobe
- Howard Weingram, TIBCO
- Rama Gurram, SAP
- Eduardo Abe, ILOG/IBM
- Kris Vishwanathan, IBM
Original agenda
- Agenda
- Discuss revised pictures at top of Managed Hub Overview chapter
- Walk though red-colored open issues in Managed Hub API chapter
Minutes
Revised pictures at top of Managed Hub Overview chapter
Jon: I took Howard's pictures and made minor modifications.
Howard: I thought we were going to remove "utilities"
Jon: It looked funny to me because Managed Hub is also part of "OpenAjax Hub"
Howard: Could remove the whole bottom layer
Jon: OK with me. I'll have to grow the remaining boxes. Any disagreements?
(none)
RESOLUTION: Remove "OpenAjax Hub utilities" boxes from pictures
Jon: I also cleaned up the text underneath, including a global search/replace where 'widget' became 'Client Application' and 'mashup application' became 'Manager Application'
API chapter: table at top
Jon: I added rows for IframeHubClient and InlineHubClient as we discussed last week. I also changed one or two occurrences of class to interface, or vice versa. Does anyone see anything wrong?
(no response)
subscriptionID writeup changes
Jon: I attempted to document the subscriptionID parameter as we discussed last week, but I wanted everyone to review the text.
Javier/Howard: Change it to "unique within whatever object implements the Hub interface"
Jon: OK, I'll change that
RESOLUTION: Change description of subscriptionID to say "unique within whatever object implements the Hub interface"
publish() method 'data' parameter
Jon: Please review the short descriptive text for the 'data' parameter on the publish() function
Matthias: JavaScript value?
Howard: We want a separate section in the spec on "JSON-serializable"
Javier: "can be" => "should be"
Jon/Howard: Or "must be"
Matthias: If an Iframe, must be serializable to JSON, but not if inline
Javier/Howard: Yes
Howard: So, instead say "should" and point to the best practices chapter
Jon: Where in the spec to write up JSON serializable? In the Intro chapter under definitions of terms?
Howard/Matthias: Yes
Matthias: JavaScript value?
Howard/Jon: Can't say JavaScript object because that would be confusing because you can also use arrays, strings, numbers, etc.
Howard: That's why value is best
Jon: Yes
Howard: This definition (of JSON serializable) is fine. But should say explicitly that it will turn into a JSON string and refer to JSON spec
Jon: Right, ok
Kin: It can be null or a number?
Howard: Yes
Jon: Should we provide a list of JavaScript primitives that must be supported?
Howard: Yes
Kin: Does every object have to provide an overwrite to toString?
Javier: Standard practice is to look for the toJSON property
Howard/Javier: But we shouldn't do anything with that
Kin: Do we use a JSON library?
Howard: We are not specifying a particular implementation. Shouldn't say toString(). Instead, "turns it into a string".
Jon: I agree with what you are saying, but I want to think about the exact wording.
Javier: Just pointing out the toJSON option
Jon: Just say JSON, but not the details of how? Isn't to/from JSON done all inside of the Container?
Howard: Yes. We want to be careful not to require an implementation to force certain things there
Jon: I'll create a separate section with an updated definition and put a red-colored comment by it so we will remember to review again
Jon: But what about the first paragraph. Any problems?
Howard: I have no problems with the first paragraph
Jon: The 2nd paragraph is pretty much directly from Howard's email. Any objections?
Howard/Matthias: No
RESOLUTION: Separate section for JSON serializable. Update per discussion above.
getSubscriberData
Jon: Howard's proposal. I said +1
Howard: This was sent to address an unresolved issue in the spec
Javier: I agree with the proposal
Jon: Any objections?
(none)
RESOLUTION: Approve Howard's proposal for getSubscriberData
ManagedHub constructor
Jon: I tried to change the spec to incorporate last week's decisions about params
Howard: Replace "Corp" with "Org"
Javier: The text about params should go with Container
Howard/Javier: Doesn't make sense here
Rama: Yes
Jon: OK, I'll do that
Howard/Javier: First paragraph is fine
Howard: Storage of private variables should happen before callbacks are invoked. Probably don't need to say this in the spec.
Jon: I agree on all fronts.
RESOLUTION: Move params paragraph to Containers, change Corp to Org
Container constructor
Howard: Make the changes Javier suggested for Managed Hub and we are fine
Howard: Also say that Container is reserved for OAA. Others should say params.somethingelse.*, not params.Container.somethingelse.*
RESOLUTION: As Howard says
HubClient constructor
Howard: I would repeat the text instead of referencing the previous text. Need to replace Container with HubClient anyway. Better to be explicit.
RESOLUTION: As Howard says
IframeHubClient constructor
Jon: Open issue - param setters. Howard says we don't need it
Howard: Don't know what would happen if you changed a param with a setter
Jon: Anyone disagree?
(none)
RESOLUTION: As Howard says
onComplete and onData
Jon: These are from a couple of weeks ago. Howard proposed one and Javier the other. So far, everyone says +1 on email. However, we haven't discussed on a phone call yet. Anyone disagree?
(none)
RESOLUTION: Accept onComplete and onData
Topic namespaces
Jon: I propose we remove this issue from here, and instead let's go over this issue when we go through the Best Practices chapter. That chapter talks about topic namespacing due to text from Hub 1.0. We may already have what we need.
Howard: Yes
Jon: Any objections?
(none)
RESOLUTION: Remove issue on topic namespaces, review the topic when walking through Best Practices chapter
Limited history
Jon: We tentatively decided to delete at the F2F. Any objections to closing this issue?
(none)
RESOLUTION: Remove issue on topic limited history
Topic payload typing
Jon: Do we need to pass datatype with each published event? We haven't found a pressing need for it, and it seems like something that should be handled at a higher level in the software that wires events together, such as in the OpenAjax Metadata spec, which has a 'datatype' attribute on the <topic> element. I studied a couple of dozens widgets that are coded in IBM's internal widget format. That technology has the option of passing a datatype with each published event, but none of the widgets uses this feature. Therefore, even when the feature is available, it isn't used.
Howard: Datatype is a higher-level concept. If we decide to not include it now, then the application can specify how datatypes are inferred by other means such as metadata or everyone knowing that a particular topic has a particular JSON type associated with it
Jon: Yes, leave it up to the application
Javier: Yes, leave it to the app. Leave our code as simple as possible. But best practice is that a given topic has a particular datatype.
Howard: Yes
Eduardo: The manager Application should know what types of data is coming. Payload type might help with discovery.
Howard: My thoughts: (a) This is in the Gadgets spec, which operates at a higher level (2) If you are receiving unknown data via auto discovery, what do you do with it? Without knowing the structure of the data, you won't know how to use it. Not every spec needs to provide all levels of information.
Jon: To do the discovery, you need information about semantics, not just the structure.
Eduardo: For simple cases, I agree with Howard. But for simple HTML tables, taking a feed, and rendering into a table data viewer, maybe this works
Howard: I don't disagree. You are working on assumption about the organization of data between publisher and subscriber.
Matthias: Agree. Semantics is shared.
Howard: There are a few cases where you could auto-discover without some knowledge of structure and semantics. But this doesn't require a type parameter.
Howard: Don't want circular dependence with metadata spec
Jon: I researched this with a couple of dozen of real widgets. No one used the payload type.
Eduardo: I agree it's high level. Still need to figure out the higher level.
Howard: Yes, we have that in process, the metadata spec. May want a best practice - either the metadata or schema provides typing. Requires app level, not Hub itself.
RESOLUTION: Delete the data type issue
Spec editing technique going forward
Jon: I am proposing the same color-coding strategy as is being use by the IDE WG
(no objections)
RESOLUTION: Adopt the same color-coding strategy for the spec as is used by metadata spec
Updating from 1.1 to 2.0
Rama/Howard: Hold off a bit longer
Jon: Would be good to do it sometime soon to help with promotion.
(someone): When will we be done
Jon: Shooting for voting on final spec starting in March sometime
Howard: A little before then, do the switch
Kin: What about a 2.1?
Jon: I don't remember anything on a 2.1 list
Howard: Maybe RPC. Need to start thinking about 2.1 fairly soon.
RESOLUTION: Hold off longer before jumping from 1.1 to 2.0
Next meeting
Jon: I made changes to Container chapter. We should review those. I have to finish the mashup chapter, and then we can look at it. We haven't looked at Best Practices chapter or Intro chapter yet.
Jon: But we need to start talking about test cases. Start that discussion next week?
Howard: Yes, good idea.
