[OpenAjaxIDE] Bootstrapping

Rich Thompson richt2 at us.ibm.com
Tue Oct 23 13:53:37 PDT 2007

I too would prefer to not start by doing separations where we do not have 
well developed reasons for the distinctions. It is likely some such 
distinctions will arise as we move forward and that seems like the 
appropriate time to separate the information.

I also wonder about an approach that seems to be focused on a downloaded 
directory structure. In particular I'm concerned about how it maps to a 
web widget model. What about more of a URI approach where "discovering" 
the widget/component/library means one has been handed a defined set of 
metadata. This could be by ingesting the response from a URI or by reading 
a file. If it makes sense to partition the metadata, this top level set 
can point to other metadata (and thereby also support deferred loading of 
unused information ...).

Rich Thompson

Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>
Jon Ferraiolo/Menlo Park/IBM at IBMUS
"ide at openajax.org" <ide at openajax.org>
10/23/2007 04:35 PM
Re: [OpenAjaxIDE] Bootstrapping

Well, it’s also still not clear to me why we need different formats for 
lib, api and widgets. What’s the difference between lib and api?
From: Jon Ferraiolo [mailto:jferrai at us.ibm.com] 
Sent: Tuesday, October 23, 2007 1:27 PM
To: Bertrand Le Roy
Cc: ide at openajax.org
Subject: RE: [OpenAjaxIDE] Bootstrapping
Does your response mean that everything else in my email is good? I assume 
that the answer is no, and that your response represents only the subset 
of things you could think of at the moment. In any case, it would be good 
if you and others could respond with what parts sounded good and which 
ones didn't.


Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>

Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com> 
10/23/2007 01:18 PM


Jon Ferraiolo/Menlo Park/IBM at IBMUS, "ide at openajax.org" <ide at openajax.org>



RE: [OpenAjaxIDE] Bootstrapping

A few points: 
· I’m a little uneasy about having the name OpenAjax (or even something 
generic such as metadata) as the file name because if the file gets 
separated from the library or gets out of the folder, you can’t guess 
what’s in there without opening it. I’d prefer a convention that is a 
variation of the library’s file name. i.e. prototype.js -> 
· We shouldn’t force people to put different libraries in different 
folders if they don’t want to.
· The file should be discoverable from the directory where the file sits 
as well as from some central directory on the file system that’s 
determined by the IDE itself. This enables web authors to not have the 
metadata file pollute the web site if they don’t want it there.

From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On Behalf 
Of Jon Ferraiolo
Sent: Tuesday, October 23, 2007 12:52 PM
To: ide at openajax.org
Subject: [OpenAjaxIDE] Bootstrapping
(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 

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 

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.

IDE mailing list
IDE at openajax.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071023/2c71dd13/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071023/2c71dd13/attachment.gif 

More information about the IDE mailing list