IDE Minutes 2007-11-01

From MemberWiki

Jump to: navigation, search


Attendees this week

  • Lori Hylan-Cho <lorihc(at)>
  • Ingo Muschenetz <ingo(at)>
  • Kevin Hakman <khakman(at)>
  • Ted Thibodeau <tthibodeau(at)>
  • Jon Ferraiolo <jferrai(at)>
  • Bertrand Le Roy <Bertrand.Le.Roy(at)>
  • Phil Berkland <berkland(at)>
  • Jim Driscoll, Sun
  • Rich Thompson, IBM


  • Kevin: Thanks to Jon for putting together the Strawman proposal.
  • Jon: There’s lots of material here now. So people need to look at this in detail on their own, but today we can go through a general tour and I can highlight key aspects of the proposal. There are lots to stake holders on widget side in particular. There are widget efforts in the Gadgets task force and we’ll have to reconcile with the W3C as well.
  • In brief I put together:
  • OpenAjaxWidget.xml type file for use with an authoring tool focused on visual authoring e.g. jmaki, Netbeans, UI within an app, then linking together; Dreamweaver – focused on controls, then customizing those controls, linking topics and events to each others. Aptana on the other hand does not support widgets in this concept.—focused more on JS APIs – things developers call as utilities. Eclipse ATF.
  • OpenAjaxAPI.xml is more aligned with tools focused on authoring against APIs—not visual widgets… for example Aptana strong in this area.
  • Kevin: There’s 80/20 rule here in my experience – Widgets and APIs are not mutually exclusive. With TIBCO General Interface you only spend 20% of the time rapidly assembling and configuring visually since it’s so fast to do that, then perhaps 80% of the time coding against APIs to implement the behaviors of your Ajax application.
  • Jon: Yeah so I handed that in the proposal by using the same schema to describe things like properties and event in both files.
  • Kevin: Got it – a shared schema to the extent there’s overlap. Such as for Properties, events.
  • Jon: Eclipse ATF has widget focus, but also facilitating APIs.
  • Phil: code completion is a big focus for us.
  • Kevin: OK, Jon, take us give us the grand tour:
  • Phil: need for 3 files, or can be consolidated?
  • Jon: 3 files follow existing conventions.
  • Lori: more than one widget case in a single document be handled.
  • Many: Allow for multiple widgets in the same file was proposed and supported my all on the call. <widgets> perhaps at tope level <apis> at top level?
  • Jon: I looked at multiple widget definitions and kits form dojo to Apple to Google to IBM’s proposal to Gadgets, W3C widget spec, and Sun’s jMaki.


  • Example 1: clock example using jmaki’s data which wraps dojo clock. Proposal re-expressed this in an XML format with 1:1 transformation with the .json code used by jMaki.
  • Most significant change was in properties area: in the properties area: arguments in jMaki end up in property inspectors – but to consolidate to how properties look in the Widget side and the API side, the property stuff comes from Aptana’s treatment of properties. Type types .js and .xsd: E.g. positive integer type in js would be “Number” and in .xsd would by “Positive Integer” (if that's right for xsd but you get the idea).
  • For properties areas tried to express attribute or sub-element for that feature. For example from Adobe… attributes on the widget tag, you’ll see the “about” attribute,
  • Lori – author attribute could be better expressed as <author> tag so that we can provide more detail.
  • Jon: Right -- so our process would be that we’d review each of these tags and attributes and refine these over the next few weeks.
  • Lori: Cool.
  • Jon: Other things to highlight: Some W3c items… like the License attribute, or further down at the bottom … metadata relating to mashups and desktop installable widgets…. e.g. aspect ratio, auto scrolling, etc… all from category 3 … apple dashboard and mashup types of widgets.
  • Another section: pub/sub metadata section towards the bottom: This is what the mashup people, some need… a list of topics that a particular topics that a widget will produce and consume. Then mashup tool can provide UI for linking between these.
  • Bertrand: visibility, y/n may not be best values… but question about .js type and .xsd type… why do we need both .. why not just pick one.
  • Jon: We’ll discuss that’ it’s an important questions…. I assumed that some would be .js typing …
  • Bertrand .. feels like js type is more.
  • Lori: No – need more data than just js type
  • Bertrand: Agree that we need constraints that go beyond js type. Perhaps no .xsd type, but something else closer to javascript.
  • Jon: I took a stab at it, but will require lots more discussion.
  • Kevin: Sounds like a good discussion, we’ll come back to it later.
  • Jon: there are other stakeholders with interest… Gadg4ets Task force has a widget element in it... I’ve attempted to capture the IBM proposal in this data. Gadget task force very interested in that overlap.
  • Kevin: other stakeholders? ... W3C ...
  • Jon: W3C... is only over in Cat 3 – installable desktop widget ... particularly mobile.
  • Kevin: strategy is superset of features of W3C. Therefore is they add a new feature, then we have to adjust to that.
  • Jon: Going to W3C next week with #1 object to liaison with that W3C committee.
  • Ingo: Jon, nice Job capturing. Visibility in APIs is more than just public/provide, we also use Internal as a value here a *3rd item for use in cases where it’s hidden from developer for APIS, but included in help docs.


  • Jon: Let’s look at the PI side...
  • Used a mature shipping product as the basis ... in this case started with Aptana who has excelled in this area.
  • One change made: ...two things... js type, xsd type ...
  • Changed outermost tag to address MSFT requirement for extensibility… adding attribute apiType=”javascript”. Hoping that Bertrand from MSFT will help to assure extensibility and cross language support.
  • Ingo: Aptana also supports ruby, php, so we’re interested in multiple languages as well.
  • Jon: change to properties element from Aptana’s proposal as well … adding some attributes to the property tag to address the requirements of Widgets primarily, e.g. “bindable” and

“bindObject” is my invention to meet the requirements document we created for data binding.


  • Jon: libraries like dojo, YUI, would include this so that when an IDE imported the library the IDE could put up “about data” for that library.
  • Kevin: Need some sort of proposal to allow discovery…
  • Jon: proposed to handle this via filenaming conventions in that “bootstrapping” email I sent to the list…
  • Ingo: naming conventions hard to enforce in my experience with lots of Ajax toolkits.
  • Ingo: in ext they generate an xml file that lists where the assets are that the library uses.
  • Bertrand: in addition to that, the naming convention should indicate the filename of what’s contained inside. ... if you move the file around, then you’ve broken everything. By including some info in the file name itself it’s easier to implement.
  • Kevin: Thanks all. Same tie next week… we’ll start top down looking at the proposed schema refining these ideas and as needed talk about broader architectural and organizational issues as those arise.
Personal tools