Interoperability Minutes 2007-10-31

From MemberWiki

Jump to: navigation, search

Full minutes: /member/wiki/Interoperability_Minutes_2007-10-31

Contents

[edit]

OpenAjax Alliance Interoperability Committee meeting minutes 2007-10-31

[edit]

Attendees

  • Jon Ferraiolo <jferrai(at)us.ibm.com>
  • Ted Thibodeau <tthibodeau(at)openlinksw.com>
  • Bertrand Le Roy <bleroy (at) microsoft.com>
  • David Boloker <boloker(at)us.ibm.com>
  • Howard Weingram <weingram (at)tibco.com>
  • Frederik De Keukelaere <EB41704(at)jp.ibm.com>
  • Suresh N. Chari <schari(at)us.ibm.com>
  • Jim Driscoll <jim.driscoll(at)sun.com>
  • Rama Gurram <rama.gurram(at)sap.com>
  • Kin Blas <jblas(at)adobe.com>
  • Rich Thompson <richt2(at)us.ibm.com>
  • Ted Thibodeau <tthibodeau(at)openlinksw.com>
  • Dipesh Patel <Dipesh.Patel(at)FMR.COM>
  • Nik Kalyani <nik(at)dotnetnukecorp.com>
[edit]

Original Agenda

[edit]

Minutes

[edit]

Topic: Hub 1.0

Jon: First off, a reminder that we have the Hub 1.0 Release Review phone call on Nov. 26

Jon: Howard sent email about whether published events are blocking and whether there is a well-known order by which events are dispatched. Follow-on email yesterday and today.

Howard: Unspecified is OK with me.

Kin: Should mention the topic in the spec one way or another. If it can't be relied on, they that needs to be in the spec.

Jon: I agree that it should be mentioned.

Howard: But mention it as being unspecified.

Jon: I'll craft language and send to the group for review.

ACTION Jon: Send proposed updated language to group for review.

Howard: If unpredictable, we need to make a small change to the test suite. One test, 3.2 I believe, relies on that.

Jon: Yes, please update that test.

ACTION Howard: Update the test that relies on a particular order of event dispatching.

[edit]

Topic: Hub 1.1

Jon: This is just an FYI. There is work going on in the open source project by the IBM engineers who contributed SMash to modify their work into something that could be considered as a foundation for Hub 1.1. Simultaneous work on proposed spec and open source. The approach is similar to what happened with Hub 1.0. This work is experimental. Once far enough along and stable, then it will be reviewed by the InteropWG and the other open source participants for suitability, and either adopted, modified or rejected for use within Hub 1.1. The hope is to have working code by end of 2007. There is an empty wiki page, shown in the agenda, where proposed specifications will be posted. IBM folks, anything to add?

Suresh: No, you have covered it well.

[edit]

Topic: OpenAjax Registry

[edit]

Topic: Critera for judging candidates

Jon: I wrote up a proposal for judging candidates. This is draft text that I hope and expect there to be critical review and feedback. Because this is an industry-wide initiative, it is important that we are express our criteria completely and carefully.

Jon: ILOG sent private email saying they liked the criteria. Plus some other things about their toolkit.

Jon: Any feedback on the overall criteria?

Bertrand: Lots of you who have looked at the MS entry. I added various legacy JavaScript functions that aren't created by our Ajax library but by background .NET features that developers sometimes use. The idea was to give a complete view of what developer should see. Therefore, our submission doesn't align with the overall criteria.

Jon: So, let's look down at the subsequent sections. I say that the InteropWG will judge each aspect separately and then each aspect is either approved, acknowledged or rejected. Approved is for submissions that align well with our criteria. Acknowledged are things that exist that do not align well but cannot be changed. Therefore, the .NET features are likely to be acknowledged, not approved.

Bertrand: Sounds good. Would be happy with acknowledge but not approved. I will resubmit with identification of which things we propose for approval vs acknowledge.

Jon: ILOG has the same sort of issues. They have legacy code that has many global objects that start with ILV or something like that.

Howard: How about submissions breaking down entries into approved vs acknowledge? With acknowledge, should provide an explanation.

Jon: I was thinking the same thing.

Jon: Back to the criteria. I assume people need some time to read the criteria carefully and send in responses. How about a week?

(positive responses)

ACTION Jon: Send email asking people to review the criteria. After a week, if things look stable, then send email asking for +1/-1 voting.

[edit]

Topic: Wildcards

Jon: Wildcards seems to be used quite a bit, at least in legacy space. I think we need them and assume that nearly all of the time wildcards would be categorized as "acknowledge".

Jon: Note that my proposal is a bit different than Bertrand's. Bertrand wanted to allocate foo$* for when foo is allocated. I propose that you need to register both foo and then also register foo$*. With my approach, the $ has no special meaning. It's just another character.

Bertrand: I like Jon's proposal.

Howard: I like the availability of wildcards.

B/H/J - all three state that wildcards are generally for "acknowledge" not approved

Howard: Maybe ILOG should register each of the legacy globals individually rather than register a wildcard.

Jon: Right.

Bertrand: I'm fine with Jon's wildcard approach.

Howard: I agree with that approach and for recognition and not approval.

Kin: Why not approve the use of wildcards, such as multiple global objects that begin with AdobeSpry?

Howard: Because it doesn't align with our Best Practices.

Jon: Major toolkits are moving towards a single global object for everything in their toolkit. There is an implicit best practice that the leading toolkits are adopting.

Jon: Better to have a single Spry object, not multiple objects whose name begin with the four letters "Spry".

Howard: Yes, if you hae a pattern of use for legacy, then use wildcards, but should be avoided if possible.

Bertrand: For debug version, I think the $* approach is good practice.

Jon: Why is it good?

Bertrand: Without it, in the debugger, you'll only see anonymous functions in the stack. In debug version of the script, you have recognizable things in the stack.

Jon: Let's bring this up in the IDE WG

Bertrand: OK. Maybe I'll pull together a better explanation with screenshots

ACTION Jon: Make a new issue out of $* approach for debugging advantages

[edit]

Topic: OpenAjax Candidate

Jon: Looks straightforward. Any reasons to not approve?

(no response)

[edit]

Topic: Sarissa Candidate

Jon: They ask some questions in their comments.

Howard: Looks like we need to have a location for comments and questions

Jon: Their first question is about version#. They may not have noticed the discussion we had about a month ago where we clarified version strings.

Howard: Maybe they are asking something else.

Jon: Is everyone OK with SarissaParseError as a global? Looks ok to me.

Howard: Yes

[edit]

Topic: What happens with subsequent releases of a toolkit?

(question about what happens when a new version of a toolkit gets submitted)

Jon: Note that all registry entries are forever. Once a global is assigned to a toolkit, that assignment is forever. If a new version of a toolkit comes out and they have more global variables, then they need to submit a new candidate that is a superset of the older submission

Howard: OK. So, if a new release adds no additional globals, no need to send in a new submission. The old one will still work.

Jon: Yes.

[edit]

Topic: Deprecated globals

Howard: Maybe we need special information about deprecated globals

Jon: Our overall rule is to provide the best possible information to the community, so identifying the globals that are deprecated is consistent with that rule.

Howard: Submissions should show the list of deprecated globals in a separate section.

Jon: This would have some ripple effects. Let me think about it and create an open issue.

ACTION Jon: Add new open issue on identifying deprecated globals

ACTION Jon: Send email to Sarissa asking about what they were asking about version# and point them to latest Hub text on the subject

[edit]

Topic: Lightstreamer candidate

Jon: My feeling is that LS global is fine in this case, even though only two letters

Howard: LS$ seems sort of short. Want to talk to Lightstreamer about it.

Jon: How about a recommendation that global variables are more then 3 letters for new toolkits.

Howard: Preferably organization names. But not necessarily a requirement for acceptance vs rejection.

Bertrand: I would add that it is understandable that toolkits need to use as short of names as possible.

Jon: Yes. Another thing for which I should write a proposal.

ACTION Jon: Write up proposed text about avoiding global object names that are too short

ACTION Jon: Ask LS why then need LS$*, explaining the approve, ack, reject stuff along with the legacy vs current stuff

[edit]

Topic: Next phone call

Jon: Maybe in two weeks, but if we aren't far enough along on enough issues, then maybe push it back to a later point.

Retrieved from "http://www.openajaxalliance.org/member/wiki/Interoperability_Minutes_2007-10-31"
Personal tools