IDE Minutes 2007-10-11
Attendees this week
- Lori Hylan-Cho <lorihc(at)adobe.com>
- Ingo Muschenetz <ingo(at)aptana.com>
- Kevin Hakman <khakman(at)tibco.com>
- Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
- Greg Murray <greg.murray(at)sun.com>
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Phil Berkland <berkland(at)us.ibm.com>
Kevin asking about Widget Task Force and whether that would be going forward.
Ingo: We ended last week's discussion by talking about having a few sample widgets that we'd use as a base for comparing implementations. Did we ever finish that discussion?
Kevin: We should definitely do this.
Info: Greg suggested the Dojo Clock Widget should be one of them.
Kevin: Yes, because it has a certain degree of depth to it.
Jon: Maybe when we get into a deeper discussion of a spec or an implementation, it'll be easier to define which widgets should be the base.
Kevin: Let's continue discussing the executive summaries, and then move on to implementation details.
Ingo: I'd rather have the base widgets sooner rather than later.
Lori: Me too.
Jon: I'm worried about getting into a waterfall approach where we go back and forth between the implementation details and the base widgets, expanding the test set, etc. But maybe it'd be ok to have a base set to start comparing.
Ingo & Lori: That works.
Kevin: OK, so Dojo Clock...
Lori: And I already did Spry Tooltip.
Kevin: Should we do a datagrid? Or a map?
Jon: Or the Open Ajax Hub?
Kevin: So, the clock, the tooltip, the hub, and some standalone function thing?
Bertrand: How about a component that talks to the server? Like an Auto-Complete component?
Jon: Yes, a widget that talks to the server is something that we should look at relatively early, but it's OK with me to push this off to the second wave.
Kevin: We need to find an auto-complete...
Lori: There's a Spry one, a YUI one...
Greg: Scriptaculous seems to be the one everyone likes, prototype has one... What about a spell-checker?
Jon: Why don't we go with Auto-Complete for now.
Greg: Trees and comboboxes are widgets that everyone wants to use.
Bertrand: Maybe the framework vendors should contribute test cases?
Kevin: Let's try to tackle three widgets/frameworks up front, as a start. Dojo Clock, Scriptaculous/YUI Auto-Complete, a Spry widget or the Open Ajax Hub (non-visual), maybe a non-visual XMLHttpRequest widget.
Greg: Flash sound?
Kevin: I'm proposing the OAA Hub, YUI Auto-Complete, Dojo Clock, straight-up JS function. What should the characteristics of the JS function be?
Ingo: Is it meant to represent a simple snippet of code, or is it meant to complement the Hub because the Hub has such a basic API?
Kevin: It's conceivable that someone could write a JS function and document it such that an IDE could take advantage of the documentation...
Ingo: What about the $ function, which everybody uses?
Jon: I think we should crawl before we walk, and $ is more of a walking function.
Ingo: I'm OK with just having three right now, since I'll need to write these, and I'm pretty pressed for time.
[laughter likely indicating agreement]
Ingo: Our current metadata format comes from a library perspective. Looking at adding more widget-specific descriptions. Currently have two XML files -- one a library description, and one an (installation?) file. Use JSDoc-type syntax; also read in XML-style description. Generate documentation on the fly from XML or meta-data on top of the JS.
Bertrand: What is SUpdate?
Ingo: It's an idea we had... [something about microformats] ...but not part of our proposal initially.
Ingo: We allow for multiple parameters, multiple return types, info about browser compatibility, whether it's tied to some sort of standard, etc.
Jon: I'm looking at some of the samples... <availability> tag, <browsers> tag...
Ingo: There's some inheritence here (relating to browsers).
Phil: Any thought to doing it the other way around?
Ingo: You mean specifying the browsers that it *doesn't* work on?
Ingo: We considered it, but we're expecting that people would be relying on specific browser extensions to HTML, and thus it's easier to say that I know it works in this browser.
Bertrand: How do you handle the localization of this file?
Ingo: Currently we'd need separate XML files, but ideally we'd just separate out the localizable bits. All you'd really need to localize are the descriptions and the examples, which is very straighforward.
Kevin: Well, all the languages that support constructors, variables, etc.
Ingo: Right. PHP and Ruby are also being considered.
Jon: Any thought to JS 2?
Ingo: First we're focusing on JS 1.8, then JS2.
Jon: What's 1.8?
Ingo: It's going into Firefox 3.
Jon: Does it allow for namespacing?
Ingo: I don't think so; I think that's going into JS2.
Jon: So 1.8 is still based on spidermonkey, and JS2 will be based on tamarind?
Ingo: We definitely are handling namespaces, because we had to for Adobe AIR. The types include the class names. We do allow for classing, superclassing, and there are datatypes. I also like the idea of having subtypes to prompt the IDE for what *kind* of string, for example, goes here.
Kevin: I like the subtype stuff that Lori did.
Ingo: We tried to stick to JS as JS to be true to the language. Had to resist the urge to specify things as "int" rather than "number".
Bertrand: [can't hear]
Ingo: [can't hear]
Bertrand: We have something similar for DOM elements, which are basically objects... we have a special Boolean for that too.
Ingo: How do you handle the case of a width in CSS, where it could be anything from pixels to %?
Bertrand: Currently we don't. But we should. We let the code handle it.
Kevin: Ingo, there were some cases too about arrays -- how you would describe an array or an enumerated list of options. Have you thought a little bit about that? It goes outside the 'strictly sticking to JS' plan.
Ingo: I think we should allow for a list of valid values supplied by the developer. It's not in there currently, but it's something we plan to add.
This is, internally, how we describe... [missed]
Kevin: We've talked about whether we could go back and forth between the XML format and the JavaDoc/JSDoc format to make comments in the code... Ingo has posted another example that shows that. Can you describe?
Ingo: See http://www.aptana.com/docs/index.php/ScriptDoc_comprehensive_tag_referen ce. Should look familiar to anyone who knows JavaDoc. 1:1 mapping between the @things and the tags that exist in XML. Interesting syntax down at @param... user can put in a list of types, specify that some are optional, use "..." syntax to specify "1 or more", etc.; not a 1:1 mapping in this case.
Kevin: Can you describe the other file that handles dependencies and packaging?
Ingo: Internally it uses [something] points, but to end user it's just an XML file. It describes where the dependent files can be found/should be stored. I can put an example up in a moment; don't have one handy.
Bertrand: Do you have a schema for your XML?
Ingo: Yes. We've been using InfoPath to edit it.
Ingo: We've had pretty good luck documenting the existing libraries out there using this format, so what we're mostly looking to do is extend this format based on these discussions.
Bertrand: Sometimes we package the metadata for manage code library along with the JS library, and we need to differentiate them somehow, and we can't do that with a fully-qualified name. So we need a unique ID that's different from the fully-qualified path. It would be helpful to have an ID attribute for that purpose.
Ingo: Can you send me an example of that?
Bertrand: You can find it in the MS proposal.
Kevin: This has been great. Looking forward to hearing about the Microsoft proposal.