IDE TF Minutes 2007-04-05
- Greg Murray <greg.murray(at)sun.com>
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Kevin Hakman <khakman(at)tibco.com>
- Phil Berkland <berkland(at)us.ibm.com> representing Eclipse ATF project
- Ingo Muschenetz <ingo(at)aptana.com>
- Yossi Leon <yossi(at)zend.com>
- Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
- Task Force Processes
- Discuss drafting an "Integration Charter" towards Working Group formation.
- Review & refine requirements
- Set future meeting dates and times
- Any Other Business
- Wrap up
- Task Force Processes
KH: Welcome MS and Bertrand. Glad to have task force growth and glad to have MS. Lots of press coverage of MS joining OpenAjax Alliance.
BLR: We are excited also.
KH: Looing at how Ajax can work with tooling. MS has lots of tooling experience. Looking forward to your thoughts.
BLR: We are very interesting in having VS participate going forward.
KH: How much up to speed are you?
BLR: Not much.
KH: Probably good to do a quick recap. Looking at strategies that are feasible. Now aobut ready to recommend formation of a WG, where TF is a more informal research group. WG would probably develop spec that would be treated as a standard.
KH: In past we have done a survey of approaches that toolkits and devel tools have taken. EG Aptana has discussed their code scanning approaches. TIBCO with their visual designer, drag&drop and inspectors. And lots of great work from Greg's jMaki. Goal to support multiple toolkits. Lots of insights and harbinger of ideas.
KH: Supplemental file that drives design-time via metadata. And then additional snippets to support server frameworks, including JSF, JSP and PHP.
GM: Only thing that has prevented support for ASP has been lack of time.
KH: Also entries about Eclipse/ATF. Jon researched GoLive, Dreamweaver, and Flex. Also Java Beans.
KH: Also, there is a placeholder for Visual Studio for extensibility and external libraries. Would be great to have those filled out.
KH: On wiki, there are also use cases and requirements. For requirements, we have about 50 bullets. In one hour, we only got through first 6 bullets. Maybe not worth our time to focus on requirements right now, but instead work on a charter, and have WG finish work on requirements.
KH: But requirements thrust is standard metadata for describing widget, visual and non-visual. Obvious low-hanging fruit: name, types, mthods, param types. Then a set of requirements that are more complex: versioning, dependencies on libraries, events, behaviors.
KH: Also, a lot of discussion, where we were initially focused on client-side authoring such as Dojo and GI, but then realized that lots of metadata is useful in server-side workflows
BLR: Can you explain?
KH: Metadata that describes metadata can work for both JS markup as well as code-based or markup-based on server side
KH: Any other points?
JF: Can't think of any
KH: What is process of writing charter? Any advice?
JF: Simple thing would be to use one of the existing charters and modify from there. The process kicks off by someone volunteering themselves as the lead, which would probably be you.
KH: OK, I am willing. Anyone else interested?
KH: Anyone object to me doing this?
KH: OK, no objections, I'll do it.
JF: I'll send you an email about what the procedures are.
KH: What are thoughts about the scope of the WG? Client vs server? What is the name of the WG: IDE WG or Integration WG?
JF: I would rephrase as IDE Integration or just plain Integration. I'm not sure myself what's the best way. IDE Integration will be a misnomer if our metadata turns out to be useful in other settings like server frameworks. Integration will look silly if it turns out to be only oriented around IDEs.
KH: Not sure which is best, either.
KH: Maybe we should say design-time?
BLR: We use same metadata for design-time and run-time. Also use it to drive documentation.
KH: How used at runtime?
BLR: Have a declarative markup syntax. Like XAML or XUL. Used more previously.
KH: Anyone else have an opinoion about design-time vs run-time?
JF: Perhaps our requirements could say MUST for design time, MAY for run time
BLR: Sounds good
IM: If we work on runtime issues, we might overlap with other groups
JF: Yes. This might be good or bad. Good if it leads to greater integration among the OpenAjax technologies. Bad if there are overlapping and incompatible specs.
KH: What should we not do?
JF: We shouldn't define an all-encompassing component framework that requires toolkits to be rewritten
BLR: Don't want to require a particular approach or format for including the metadata. OK to generate it from something else. Doesn't matter how the original source material is organized.
KH: I concur with that point of view. Have looked at JS commenting conventions. But weren't thinking of requiring that approach.
(Kevin has to leave)
JF: Kevin wants to have phone calls every week if people are willing to do that so that we can accelerate our progress
GM: JavaOne is coming up. Won't be able to attend them all, but most of them. Probably can cover between Craig and I.
IM: May not make every single call but 80-90%
PB: Works for me
JF: Anyone object to phone calls every week?
Jon: OK, every week
Jon: Before next week, it seems to me that we should start email discussion about the name of the WG and have a draft charter under development.