Interoperability Minutes 2008-01-30

From MemberWiki

Jump to: navigation, search

Full minutes: /member/wiki/Interoperability_Minutes_2008-01-30

Contents

OpenAjax Alliance Interoperability Committee meeting minutes 2008-01-30

Attendees

  • Jon Ferraiolo, IBM
  • Bertrand Le Roy, Microsoft
  • Thomas Madej, Furi Enterprises
  • Kin Blas, Adobe
  • Javier Pedemonte, IBM
  • Rich Thompson, IBM
  • Phil Berkland, IBM
  • Adam Peller, IBM

Original Agenda

Minutes

Topic: Issue 1: DOM Extensions

Jon: I sent in a proposal. Bertrand, who submitted the requirement originally, like it.

Rich: Is the syntax extensible beyond DOM extensions?

Jon: For features that would be defined by OpenAjax, yes, for example could have something like !Plugins.whatever if we wanted to define extensions that had to do with browser plugins, not that that makes sense. For features that would be defined by third parties, my best answer is that they can include text within their free-form registry comments.

Rich: I think that is reasonably extensible.

Thomas: Does the syntax apply to every object instance or is there a mechanism for single object instances?

Jon: If you don't include "prototype" then it would apply to single object instances. That's the general rule, not just here.

Rich: What about extending built-in types?

Jon: Do you mean JavaScript language types such as Array?

Rich: Yes

Jon: We just use "Array" or "Number" for that case.

Rich: How about !JS.Array to identify as a JavaScript language extension?

Bertrand: "Array" and "Number" are not ambiguous in any way.

Jon: Yes, we concluded that it is OK and appropriate to simply refer to built-in types directly.

Rich: I'm OK with that.

(everyone OK with the proposal - no objections to closing the issue)

Topic: Issue 4 on wildcards for IDE workflows

Jon: This has been discussed previously, first in the IDE WG which said that this approach was reasonable, legitimate and valuable to developers, then the Interop WG accepted this approach. Did I just forget to close this issue?

Rich: We decided to leave it open to allow other committee members a chance to review before closing. No one has objected.

Jon: Any objections to closing?

(no objections)

Topic: Issue 5 on jQuery conflict avoidance approach

Jon: I don't believe there is any technical issues here, we already decided that jQuery was doing something reasonable and that we should recommend similar approaches. The question is whether my write-up is good.

Bertrand: Write-up is good but not complete. Doesn't mention built-in types or DOM extensions except in the intro. Need recommendations for the other types of extensions.

Jon: I will add that text, send to the group, and leave issue open until people have had a chance to provide feedback.

Thomas: What is our policy about how toolkits should work? jQuery actually takes over $ always, but saves the old $ in $_, and then allows jQuery.noconflict() to restore the old $.

(agreement that the current text needs to be reviewed and probably adjusted to be clearer about how jQuery.noconflict() works.)

Jon: I will fix those words, too.

Thomas: The $ example is simple, but there are more complex situations where there are multiple conflicts. Are we going to recommend that the jQuery approach be used for each of the conflicts?

Jon: The key is to describe what a toolkit needs to do generically to avoid conflicts but not mandate any particular approach. You should avoid conflicts, and here are some recommended techniques you might use.

Bertrand: Only need to address conflicts with high probabilities like $. Ok to leave jQuery alone without worrying about conflicts with that name. Need to have text to say that shortcuts should be available to the app developer but the toolkit itself should use the full name always.

Thomas: Yes, your toolkit should use the namespaced approach.

Jon: Yes, but we have to word it so that we aren't mandating a particular approach, just recommending.

Rich: One bit of trickiness. There are toolkit developers, component developers, and app developers. May need different recommendations for each.

Jon: Can't close this one yet.

Topic: Issue 6 OpenAjax.Registry.libraries

Jon: From a marketing perspective, I think it is better to have a single Registry that manages multiple things than to have multiple registries for different purposes.

Bertrand: Fine with me.

Jon: Any objections to the approach?

(none)

Jon: Any objections to closing the issue?

(no objections)

Topic: Next steps with Registry

Jon: Here is my proposal:

  • Finish off issue 5 via email
  • Send out a call-for-review email to ask people to read the entire Registry wiki page top to bottom and comment on its contents. Include a deadline for when review needs to be complete
  • Review all registry candidates that have been submitted so far and make decisions
  • Publish what we have and send email to public for them to review
  • After all of the above, move towards finalization and approval by membership and Steering Committee

Jon: Any comments on this proposal?

(everyone is fine with this approach)

Jon: Next phone call in 3 weeks (Feb. 20)

Personal tools