[OpenAjaxIDE] Issue: Shortening our filenames

Jon Ferraiolo jferrai at us.ibm.com
Tue Jul 29 10:56:32 PDT 2008

Another topic for today's phone call:

When I created a validator widget for the InteropFest, the XML file ended
up with the following name:


Pretty ugly, huh?

Here is the reasoning behind the above name:

* The leading underscore (_) is a widget naming convention within the
mashup tool that indicates that this widget should be moved to the top of
the widget list. There are lots of other approaches to achieving this
effect, but that's the one I am proposing for now.

* The string "InteropFestValidator" is meant to be used by the mashup tool
to popular the widget palette. Maybe we should use the 'name' attribute on
the <widget> element instead.

* The final string "OpenAjaxWidget.xml" is required by our spec.

Can we have a discussion today about whether there are better naming
strategies for our metadata files? Here are some options that come to mind:

(1) Use .oam as the extension instead of .xml. (There are no listing
for .oam at http://filext.com/alphalist.php?extstart=^O) The main
disadvantages to .oam would be:

(a) The metadata files would not open automatically as XML files when
loaded into browsers or authoring tools. The user would have to use "Open
(b) Tools couldn't distinguish between widget files vs API files vs library
files simply by looking at the filenames
(c) We would need to figure out whether we needed to do any formal
registration for the MIME type (e.g., application/oam+xml)

(2) Use .oamxml instead of .oam to emphasize the XML nature of the file.

(3) Use .oam.xml.

(4) Use multiple new file name extensions, such as .oamw, oami, and .oaml.

(5) Keep our current approach, but come up with a shorter string for each
of the file types. For example, oamw.xml, oami.xml, oaml.xml.

My current favorite is (1), which would mean switching to a .oam extension,
but require that any library XML files be have the string "library.oam" or
"Library.oam" as the final characters in the filename so that tools could
process the library file first (because the library file might contain
information that applies to all of the other files, and maybe in the future
we might allow for the library file to contain a manifest).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080729/fe4a83e5/attachment-0001.html 

More information about the IDE mailing list