IDE TF Minutes 2007-04-12

From MemberWiki

Jump to: navigation, search



Attendees this week

  • Jon Ferraiolo <jferrai(at)>
  • Kevin Hakman <khakman(at)>
  • Phil Berkland <berkland(at)> representing Eclipse ATF project
  • Bertrand Le Roy <Bertrand.Le.Roy(at)>
  • Wayne Beaton <wayne(at)>

Absent this week

  • Greg Murray <greg.murray(at)>
  • Ted Thibodeau <tthibodeau(at)>
  • Andrei Dragomir <adragomi(at)>
  • Ric Smith <richard.allen.smith(at)>
  • John Crupi <john.crupi(at)>
  • Paul Colton <paul(at)>
  • Ingo Muschenetz <ingo(at)>
  • Frank Nimphius <frank.nimphius(at)>
  • Shane Caraveo <shanec(at)>
  • BJ Hargrave <hargrave(at)>
  • Alex Russell <alex(at)>
  • Yossi Leon <yossi(at)>
  • Andre Charland <andre.charland(at)
  • Mike Han <mike.han(at)>
  • Bruce Johnson <bruce(at)>

Original agenda


Kevin: Thanks to Jon for rounding out the charter

Jon: Thanks to Kevin for writing the core of it. Who will take minutes this time?


Jon: I did them last time on conditition we'd rotate minutes duty.

Kevin: That's right Jon. Those were the expectations everyone agreed to last time. I'll do it this time on condition that we rotate. Anyone object?


Kevin: OK. So it's agreed.

Kevin: The top of the draft charter is boiler plate citing the processes outlined in the governing docs: The Members Agreement and the Development Process. There's a schedule as well and we can fill in those dates and target timelines later. The process also calls for their to be an initating member organization and a project lead. Last time TIBCO and myself were nominated for that. I'm happy to take that on. Are there any other nominations?


Kevin: OK. Any objections to TIBCO/Kevin taking on those roles?


Kevin: OK. No objection to TIBCO/Kevin.

Wayne: The draft has Schedule is in there twice.

Kevin: Thanks. We'll fix that in next draft.

Kevin: The next section deals with definitions. THere's been complexity around the terms “Component”, "widget", "toolkit" and I suggest that we not take those on right now, but instead come back to these later.

Jon: I avoided word widget in my part of the charter draft and Kevin avoided the word component.

Bill: In the first line it states "Ajax widgets", seems that we also want to address collections of widgets in “toolkits”.

Jon: “when looking at palette it’s a list of widgets; but when looking at APIs often these are aggregated into APIs for a toolkit or a collection of things.

???: "Maybe should say widgets and APIs."

Jon: Bad to have multiple definitions. In fact somewher eon the wiki we already have a definitions section and should not contradict the definitions there.

Kevin: Yes we want to look at that and use those terms here as well.

Bertrand: In ASP.NET we use the term “Control”, and "Behavior", etc...

Jon: Control I like that.

Kevin: Yes. The problem with widget is that is connotes the visual GUI stuff while we walso want to address data, communications, events, behaviors -- the non visual stuff that's part of Ajax authoring in IDEs too.

Kevin: How about “Visual and non-visual Controls and their APIs” in the first sentence?

Kevin: Any objections to both "design time" and "runtime" scope?


Jon: Actually, re: “The component integration specifications will target design-time integration with IDEs as the primary use case, but the WG will develop appropriately generalized technologies on an opportunistic basis to maximize reuse in other usage scenarios, such as design-time integration with Ajax server frameworks or runtime-integration in mashup environments. The design time is the primary focus, but we believe there may also be creative runtime uses for the same data as well so we'll want to be opportunitstic there if we can.

<there was some discussion about including server side and client side authoring in the scope of the charter>

Jon: perhaps take out “design-time integration with Ajax server frameworks or”

Jon: Are we focusing on developing for the server-side implementaiton styles (e.g. JSP, .ASP), the client (TIBCO, Dojo others) or both.

Jon: Support both.

Bertrand: Both.

Kevin: Any objections?


Kevin: Both it is.

Jon: You'll need to tweak weasel word (aka "component") paragraph for clarity.

Kevin: OK. Onward to the 4 bullets… #’s 1 – 4.

Wayne: The "libraries and widgets and widgets based on libraries" stuff is wordy.

Kevin: OK, I'll change that to: “Visual and non-visual Controls and their APIs.” and carry that concept throughout.

Phil: one thing I’ve noticed … various ajax libraries will have a debug version, then runtime version.

Kevin: debug-time, covered in IDEs so we’re broad enough to cover that concept

Phil: we should mention that IDEs include debugging

Jon: yes, define IDE, to mention that some do debugging

Phil: could realize that there a situation in which we want debugging. One scenario: places where the JS is generated from XML, the debugger needs to debug the original XML source, not the generated JS. Some kind of metadata that points to the source file in the generated javascript.

Kevin: Anyone notice my typahead typo in #3.

Kevin: No objections to the next 2 items? • The WG may pursue industry-wide activities on behalf of the Ajax IDE industry, such as collecting and publishing market research. • The WG will leverage work to date from the IDE Integration Task Force (


Kevin: OK. Last item.

Jon: Mobile scope.

Phil: first ??? replace with “development”

Jon: Or "IDE issues"

Phil: yeah

Jon: then get rid of the other question marks.

Kevin: priority of mobile? seems the tech there is immature, but that connotes both deferring activity as well as getting started now to have a standard approach early to avoid balkanazation that's already rampant in other mobile standards.

Jon: likely scenario mobile ajax toolkits and components will have a high degree of overlap.

Phil: should be "issues for IDE for developing Ajax for the devices".

Jon: Please clarify

Phil: IDE issues associated for Ajax development to run on variety of devices.

Jon: Yes that makes sense.

<discussion about other things required by the Development Process for the charter>

Jon: process must specifically list inclusions and specifically list exclusions of topics to be addressed by the working group. I’ll add editorial not that we need to add such things.

Kevin: can you give example of inclusion and exclusions.

Jon: 4 bullets there already are the inclusions. Exclusions part is open. I'll add an editorial note that we need to write what we're not going to do. Obviously we're not going to [open a pizza parlor] (grin). But we need to name related things that one might assume we'd do, but we're exclusing it. We'll have to put some thought into that.

Kevin: OK. What about a name for the working group proposal?

Jon: how about “IDE Working Group”

Kevin: Any objections?


Kevin: I'll revise and send to comments and revision through the wiki. Looks like next week we can review and "freeze" for member review and comments.

Jon: Yes that's the process.

Kevin: same time next week?


Kevin: OK. Thanks everyone.

Personal tools