[OpenAjaxIDE] OAA IDE WG Minutes 2007-11-01
khakman at tibco.com
Thu Nov 1 10:36:23 PDT 2007
IDE Minutes 2007-11-01
Lots of discussion today. Not certain I caught it all in the notes.
Please notify Kevin Hakman if there are any important additions to the
Attendees this week
* Lori Hylan-Cho <lorihc(at)adobe.com>
* Ingo Muschenetz <ingo(at)aptana.com>
* Kevin Hakman <khakman(at)tibco.com>
* Ted Thibodeau <tthibodeau(at)openlinksw.com>
* Jon Ferraiolo <jferrai(at)us.ibm.com>
* Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
* Phil Berkland <berkland(at)us.ibm.com>
* 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
* 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:
* <nav to this kink:
* 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
WIDGET XML FILE
* Jon: See these widget categories @
* 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
* 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.
* 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
* 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
* 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
* 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.
API XML FILE
* 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
Bertrand from MSFT will help to assure extensibility and cross language
* 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.
LIBRARY XML FILE
* 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
* 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.
Director, Developer Evangelism
Co-Founder General Interface Enterprise Ajax Toolkit
P: (415) 225-4259 E: khakman at tibco.com
TIBCO Software Inc.
All information in this email is proprietary and confidential.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IDE