[OpenAjaxIDE] Bootstrapping

Jon Ferraiolo jferrai at us.ibm.com
Tue Oct 23 12:52:08 PDT 2007

(I'm only sending this to ide at openajax.org because this is mostly centered
on IDE workflows, not mashup workflows, although this proposal does attempt
to address some of the expected requirements from the Gadgets TF)

We have looked at various grammars (XML, JSON and JSDoc) for representing
library metadata (APIs and widgets). At our last phone call, there was a
sense that we would be able to take the best features from each of the
proposals such that we could define a unified XML grammar that might
address all of our requirements. This is all good.

My question today is how does it all get bootstrapped (i.e., discovered,
loaded, initialized)? Let's assume we have an IDE and two Ajax libaries,
"A" and "B". How does the IDE discover A and B, make them available to the
IDE, and how does it find (or possibly auto-generate) the XML metadata
files that describe the APIs and widgets?

Here is one approach that might work:

1) An Ajax library is assumed to have a root folder, and everything needed
by the library descends from that root folder. It is assumed that the IDE
"discovers" a given library either because the library ships with the IDE
or the library can be imported into the IDE somehow (post-installation),
and the key thing that the IDE needs to know is the name of the root folder
for the library.

2) To bootstrap library metadata, a file named OpenAjaxLib.xml file SHOULD
exist in the root folder. This file provides overall metadata about the
library (e.g., version#).  But note the word "SHOULD". It is OK if
OpenAjaxLib.xml is separate from the library, in which case the IDE will
need to collect the metadata some other way, such as prompt the user
provide the location of the OpenAjaxLib.xml file.

3) API metadata and widget metadata can be scattered around the directory
structure. Assume that the IDE will recursively search through directories
to find those files. No need for a master manifest file, which is difficult
to keep up to date. We simply have to come up with a standard filename for
the metadata files, such as OpenAjaxAPI.xml and OpenAjaxWidget.xml. (Note:
we might provide an optimization feature in OpenAjaxLib.xml where explicit
search paths could be defined and the toolkit developer can choose
different names than OpenAjaxAPI.xml and OpenAjaxWidget.xml)

4) We make sure that OpenAjaxAPI.xml can be generated dynamically by the
IDE through a just-in-time transformation (e.g., transforming MS's inline
XML annotations into OpenAjaxAPI.xml or transforming JSDoc inline
annotations into OpenAjaxAPI.xml)

5) We attempt to define the format for OpenAjaxWidget.xml such that:
   a) it can be used to serve all common definitions for "widget" (WUI=UI
controls, WMASH=Mashup widgets, WDASH=Installable desktop gadgets such as
   b) we make sure there are lossless transformations to/from selected
existing WMASH and WDASH widgets formats (e.g., Apple Dashboard, Google
Universal Gadgets)

6) Allow OpenAjaxWidget.xml to include API definitions that apply to the
given widget. Therefore, inside of OpenAjaxWidget.xml there might be tags
from OpenAjaxAPI.xml.

Relationship to the proposals from Adobe, Aptana, and MS, plus also jMaki:

a) OpenAjaxWidget.xml should be largely analogous to jMaki's widget.json
file, but needs to (roughly) support the union of features from Adobe's
proposals and IBM's proposal to the Gadget's TF, plus offer an
extensibility approach such that a rich UI system like dijit could embrace
this format down the road. (Not saying that dijit should do this, but the
format should allow this as a future possibility.)

b) OpenAjaxAPI.xml should be extensible in a manner that address's MS needs
for supporting other languages. (As we discussed at the last phone call.)

c) Under the extensibility veneer per (b), the description of JavaScript
APIs probably should look a lot like Aptana's markup language

Bottom line, my thinking today is that we need 3 different formats,
OpenAjaxLib.xml, OpenAjaxAPI.xml and OpenAjaxWidget.xml.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071023/87e928d2/attachment.html 

More information about the IDE mailing list