Interoperability Minutes 2007-11-28

From MemberWiki

Jump to: navigation, search

Full minutes: /member/wiki/Interoperability_Minutes_2007-11-28

Contents

OpenAjax Alliance Interoperability Committee meeting minutes 2007-11-28

Attendees

  • Jon Ferraiolo <jferrai(at)us.ibm.com>
  • Bertrand Le Roy <bleroy (at) microsoft.com>
  • Howard Weingram <weingram (at)tibco.com>
  • Jim Driscoll <jim.driscoll(at)sun.com>
  • Rama Gurram <rama.gurram(at)sap.com>
  • Kin Blas <jblas(at)adobe.com>
  • Gideon Lee <glee(at)openspot.com>
  • Javier Pedemonte <pedemont(at)us.ibm.com>

Original Agenda

  • Agenda
    • OpenAjax Hub 1.0
      • Finalize wording on pub/sub guidelines
      • /member/wiki/Talk:OpenAjax_Hub_Specification_PublishSubscribe
      • Hot new issues:
        • (Howard/Jon) Modify sentence to read: "Subscriber callbacks functions MAY publish new events and/or invoke other OpenAjax Hub services (e.g., subscribe or unsubscribe to topics, including the given topic) as part of their processing."?
        • (Howard) Remove sentence "In most scenarios, a publisher SHOULD NOT depend on whether it has subscribers or what actions subscribers might take."?
        • (Frederick/Jon) Change MUST to SHOULD: "Because of this, callback functions SHOULD treat publisherData as read-only and therefore, as a general rule, not change its contents."?
        • (Jon) Change MUST to SHOULD: "Therefore, callback functions SHOULD NOT throw uncaught exceptions."?
        • (Jon) Change MUST to SHOULD: "...developers SHOULD NOT depend on any particular invocation order"?
        • (Jon) Change MUST to SHOULD: "...developers SHOULD NOT depend on immediate execution of subscriber callback functions"?
    • OpenAjax Registry 
<prefix>: { 
  namespaceURI: <string>, 
  version: <string>,
  globals_to_approve: <array-of-strings>,
  [globals_to_acknowledge: <array-of-strings>,]
  [comments: <string>,]
  [specificationURI: <string>,]
  [extraData: <arbitrary JSON>,]
  email: <string>
}
  • where:
    • Entries in globals_to_approve must be globally unique across the entire OpenAjax Registry
    • Entries in globals_to_acknowledge do not have to be globally unique across the entire OpenAjax Registry
    • comments includes any supplemental text that the toolkit developer wants to send along with his candidate submission. It is recommended that comments identify any deprecated globals, along with any version information when particular globals became deprecated. The comments field is also the preferred location for any notes or questions that the developer wants to send to the Interoperability WG regarding his submission.
    • email is the email address for communication between the Interoperability WG and the person or organization that submitted the registry candidate
    • Once approved and posted in the official Registry, the property names are changed to globals_approved and globals_acknowledged

Minutes

Topic: Hub 1.0 pub/sub guidelines

Jon: The "talk" page has the wording that I posted on Monday. Since then there has been follow-on email. I attempted to capture the outstanding issues on the agenda regarding six things that we need to discuss.

Jon: First, per Howard's feedback, I modified the sentence that said "callbacks MAY publish events" to "callbacks MAY publish event and/or call other hub things...". What do people think of this change?

Howard: I view it positively.

Jon: Any objections to this change?

(none)

Jon: OK, I'll incorporate this change.

Jon: Next item. Howard wants to remove the sentence about publishers not depending on subscriber actions. I agree. Even if we remove this particular sentence, there are still sentences about publishers and subscribers being independent.

Howard: It depends on the architecture of your application. Sometimes publishers might first check on subscribers and then only publish if there are subscribers. It is a common pattern where the publisher needs to determine what other things are on the page.

Bertrand: Sounds good to me.

Jon: Anyone object to removing the sentence?

Bertrand: Maybe the wording doesn't convey the right thing.

Jon: The wording is tricky. We all agree on what we are trying to say. The hard part is finding words that express it in an acceptable manner.

Howard: My issue is that I don't like the SHOULD NOT in this case. Maybe I will propose an alternate sentence. If I don't, then I think the spec is fine. I think this is intended to facilitate independence interoperability scenarios but also can be used for other scenarios, like the read-write one that we describe.

Jon: Here is my proposed plan. Take the results from this phone call, merge into the proposals on the Talk page, and then update the specification wiki page with that merged result. Then ask people to review and comment. Once comments settle down, then ask the WG by email if it is OK to submit the spec for member voting. Sound OK?

(no objections)

Jon: Now let's talk about the four proposed changes where we would change MUST to SHOULD.

Howard: OK, except for the uncaught exception one, which would be better as a MUST.

Jon: But the definition of SHOULD basically says that SHOULD==MUST except when there is a really good reason.

Howard: Raising an exception is a violation of the contract. Don't see why it needs to ever happen and therefore no reason for SHOULD. Is there a reason ever to have this happen?

Bertrand: I would say that there might be a valid reason for a subscriber to want to kill the application entirely. For example, subscriber decides it is in an undetermined state, perhaps because of a security violation.

Jon: Not sure what else could be done in this case except throw an exception to stop the application.

Howard: What I want to avoid is a subscriber callback throwing an exception that it doesn't catch itself as a matter of course.

Jon: How about saying that publisher should not include exceptions in their public API?

Howard: Worried about people throwing exceptions from callbacks.

Bertrand: Yes, we want exceptions to only be used as exceptions, not as APIs.

Howard: At least continue to say that OAH is not required to include code to handle exceptions.

Jon: How about my suggestion that publishers should not include exceptions in their public APIs?

Howard: I agree.

Bertrand: Publishers and subscribers should not use exceptions as part of the shared protocol.

ACTION: JON to add a sentence that says this.

Jon: Other comments on the MUST/SHOULD items?

Bertrand/Howard: Leave invocation item as a MUST.

Jon: OK with me.

Topic: Registry

Jon: I added a new section about wildcards in globals that attempts to express what we discussed in the previous phone call. Please give instant feedback now and review later with email feedback. Any comments now?

Howard: I would like to have something that makes submitters focus about their deprecated globals and document them.

Jon: Let's talk about deprecated globals when we get to my proposed new JSON.

Howard: Otherwise, the wildcard text looks reasonable.

Jon: Next thing, I added a bullet within the criteria section that attempted to capture our discussion last time about short variable names. I generalized the description beyond just short names to the general idea about conflict avoidance, where longer names tend to have fewer conflicts than shorter names. Also, common strings like "name" increase potential conflict.

Howard/Bertrand: Reasonable. Seems to capture essence of discussion.

Kin: Isn't it subjective?

Howard: Yes, but the key thing are criteria which help us use common sense. No hard or fast rules.

Jon: Yes, that's the approach we agreed to in previous discussions.

Howard: The new text uses the word "approve". Does this mean globals-to-approve but not globals-to-acknowledge?

Jon: Not sure. There is ambiguity with the word "approve". There are globals that are submitted for approval, and then there is the whole WG process of approving a submission. I need to work on that.

Jon: Let's look at the proposed new JSON. There is globals-to-approve and globals-to-acknowledge. The former has to be unique across the whole registry. The latter does not have to be unique. For example, prototype, jquery and dwr use $. This would probably end up in the acknowledge area.

Jon: I have proposed deprecated in the comments. Not machine readable.

Howard: I would really like people to think about their deprecated globals.

Jon: New property such as globals-to-deprecate?

Howard: Yes

Jon: I thought about that, but then maybe we would want to include version information about when the global was deprecated. Might get complicated.

Kin: Perhaps just include an example in the spec about how to expressed deprecated globals.

Howard: Sounds good.

Kin: Is it true that we are allowing toolkits to collide?

Jon: The acknowledge section will usually be for things that we would like toolkits to deprecate. We want toolkits to centralize their globals on a small number of objects like gwt. * and dojo.*.

Bertrand: Can we talk about $? JQuery does the right thing.

Jon: I have an open issue on that. My thinking is that we study jQuery and DWR and attempt to consolidate their approach into some best practices. But haven't studied that yet.

Jon: Does everyone agree that acknowledged globals usually end up deprecated?

Howard: Generally, yes.

Jon: Final question. I propose a new 'email' field. In the previous phone call, I was given some actions to ask questions to some toolkit vendors. Therefore, we need a contact to send our questions.

Kin: Will that email get posted in the registry? Dangerous.

Jon: Good question. We can do 3 things: (1) No email field, (2) Email field only for submission, but stripped before posting in Registry, (3) Email field appears in both.

(agreement with (2))

Kin: Can email address do some obscuring such as (at)?

Jon: Sure. The field is informative. It can say (at) or _at_ or joe smith.com. We can hand-edit the string before sending an email.

Jon: Any further comments on registry?

(none)

Jon: OK, I'll update the registry page. Not sure when the next phone call will be. Maybe one in December, maybe not until January.

Retrieved from "/member/wiki/Interoperability_Minutes_2007-11-28"
Personal tools