[OpenAjaxIDE] Minutes 2008-07-01
jferrai at us.ibm.com
Tue Jul 1 14:52:35 PDT 2008
IDE Minutes 2008 07 01
Bertrand Le Roy, Microsoft
Jon Ferraiolo, IBM
Stew Nickolas, IBM
Ted Thibodeau, OpenLink
API chapter questions
Jon: Let's start with the email I sent titled "Some questions for Ingo (and
(1) (QUESTION SPECIFICALLY FOR INGO) The ScriptDoc XML page says that a
<method> can have an <attributes> child element, but there is no
<attributes> element listed in the ScriptDoc XML page. Is this an editorial
Jon: Question (1) is for Ingo and Aptana. Let's go to question (2).
RESOLUTION: Need Ingo/Aptana to respond to this one.
at "MyLibrary.io.xhr". Which one of the following is correct:
(a) <class name="MyLibrary.io.xhr" ...>...</class>
(b) <class datatype="MyLibrary.io.xhr" ...>...</class>
(c) <class type="MyLibrary.io.xhr" ...>...</class>
I have been assuming (a), where we use the 'name' attribute in
*definitions*, whereas we use the 'datatype' attribute when *referencing* a
class (or whatever).
Stew: Yes, that's my understanding
RESOLUTION: Yes, 'name' is for *definitions* and 'datatype' is for
(3) Same question applies to <interface>, but one more thing on
<interface>. Our spec right now has a 'type' attribute. Assuming we use
'name' to give the interface a referenceable name, I assume we don't need
'type' (or 'datatype'). Correct?
RESOLUTION: Yes, there should not be a 'type' attribute on <interface>
(4) For the <alias> element, we only have a 'name' attribute, whereas
Aptana ScriptDoc XML has both 'name' and 'type'. My thinking is that our
metadata spec should have both 'name' and 'datatype', where 'name' is
alias's name/handle and 'datatype' is a reference to thing that is being
Stew: I agree with the analysis.
RESOLUTION: Yes, <alias> should have both 'name' and 'datatype'
(5) Further questions for <alias> so that the spec can be clear. How is
<alias> used by an IDE exactly? Is the main thing that the IDE has the
option to substitute the shorter-friendlier name of the alias (e.g., "io")
in place of a longer-unfriendly name (e.g.,
"MyLibrary.shared.crossplatform.communications.io")? If there is an alias)
implements this alias (e.g.,
Jon: Bertrand, you are the person on the call who would understand <alias>
Bertrand: I don't know. I don't think we use it.
RESOLUTION: Need Ingo/Aptana to respond to this one.
(6) Right now, our spec shows a 'visibility' attribute on <constructor>,
<interface> and <class> (and presumably <field>, where I recently fixed,
some editorial errors), where visibility="public|private|protected|
internal|protected-internal". Aptana has 'visibility' and <class>,
<constructor>, <method> and <property>. It seems like 'visibility' should>
be on <class>, <constructor>, <method>, <property> and <field>. Does
'visibility' make sense on <interface> and <mixin>?
Bertrand: Yes of the first five. But also include <interface> and <mixin>.
Might be used internally in private classes.
RESOLUTION.: 'visibility' on <class>, < constructor>, < method>, <
property>, < field>, < interface>, < mixin>,
(7) I forgot what <namespace> does. Can someone remind me so I can add
to the spec?
Bertrand: For when a library defines a namespace, such as the OpenAjax
Stew: Example of "MyLibrary.io.xhr". Two namespaces, "MyLibrary" and
"MyLibrary.io", enclose the close "xhr".
Bertrand: For object that you don't typically instantiate. Can have other
namespaces or classes. May not make sense for certain frameworks such as
jQuery, but makes a lot of sense for MS Ajax.
RESOLUTION: OK, thanks.
(Jon now has enough information to do the spec work.)
...Jon gives outline of InteropFest, which covers both IDE workflows and
Jon: For IDE workflows, first thing is something to verify that an Ajax
library has or can generate proper OpenAjax Metadata. I am proposing a
library checker widget within the "reference implementation" (i.e., the
open source mini mashup editor that Stew and others have developed that
supports OpenAjax Metadata and OpenAjax Hub 1.1)
Stew: Maybe good to set up a SaaS with REST API where the backend verifies
the library, but the reference implementation contains a small front-end to
the REST API. That way the library verification can be done outside of the
Jon: Good idea
Jon: One thing to mention is that I don't have a full proposal yet for how
to implement the library checker. Library checker needs to do a recursive
search through a directory to find files that match a naming pattern.
Options include pointing the library checker to a URL and the spider
through the web site, or require people to ZIP up their library and upload
to our site for verification, or we provide a tool that they can install on
their computer in order to run the verifier. I am still thinking things
Jon: For IDE verification, it's much simpler. We just create a simple
sample Ajax library that defines some APIs and some widgets. The IDE passes
an IDE to do to claim conformance. However, during the InteropFest, I want
to make progress on open source so that there are auto-transcoding options
for popular Ajax toolkits. It would be extra credit for the IDEs to
actually load metadata from existing toolkits and I would like to get this
working. I am investigating using JSDoc Toolkit, which is based on Rhino. I
am pretty sure it is easy to add a custom back-end which generates OpenAjax
see if it is possible to insert different front-ends that can process
Aptana's @ markup, Microsoft's XML, and Dojo's format. My thinking is that
Ajax libraries could choose between a number of options for inline
documentation where there is existing open source to allow conversion into
OpenAjax Metadata, or they could create their own format and implement
their own adapters.
Bertrand: Sounds good.
Jon: Any other comments on the InteropFest?
Bertrand: About the ordering. Maybe put the IDE part at the top?
Jon: Yeah, I have been feeling uncomfortable because Ajax libraries are now
listed as the last thing. Anyone object to lifting IDEs and Ajax libraries
before the mashup items? I think that works OK because the repository line
would be last and that's the most tenuous part of the InteropFest
Stew/Ted: No objections
RESOLUTION: IDEs first
Jon: First question. What if %%whatever%% but there is no "whatever" entry
in any of the localization files? I propose that the string %%whatever%%
appears to the user.
Ted: Yes, leave the original.%%
Bertrand: Our system offers more flexibility. We allow a fallback value in
the original content. There is a 'locid' attribute on the element. If you
don't find a localized string corresponding to the 'locid', use the content
of the element as the fallback.
...long discussion about various options, most of which were complicated.
Concluded that 'locid' approach wasn't needed within <content>. Use case is
for descriptive elements, such as <description>...
...subsequent discussion about 'localizationKey' versus 'locid' as the name
of the attribute...
RESOLUTION: Use 'locid' (like Microsoft). Applies to any element that can
take text. Jon to submit detailed proposal.
Jon: I proposed the Gadgets format because it is simple and straightforward
and Gadgets is used by tens of thousands of developers, although probably
few of them have localized their Gadgets yet.
Bertrand: Our format is widely used.
Jon: You agree we would have to use a different namespace from the MS one?
Jon: Why is it necessary to wrap the text in a <value> element? Seems
Bertrand: Not needed but that's the way it is
Jon: Would be easy to transcode to/from a simpler format to fix the
namespace and add/remove the <value> element
Bertrand: Yes, sure, but wouldn't work directly with our tool. We also have
nice features like localization of binary sources.
Jon: I prefer the simpler approach
RESOLUTION: Adopt the Gadgets localization file format
Jon: How about file naming rules, such as en_us.xml and ALL_ALL.xml? Anyone
here an expert on the RFCs?
Stew: Google's approach looks straightforward and good, but I'm not an
expert about whether it is robust.
Jon: OK, I'll ask Adam Peller, who talks at conferences about localization
and did the Dojo work.
RESOLUTION: Jon to bug Adam about file naming approaches for localization
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IDE