IDE Minutes 2008 07 01

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2008_07_01

Contents

Attendees

  • Bertrand Le Roy, Microsoft
  • Jon Ferraiolo, IBM
  • Stew Nickolas, IBM
  • Ted Thibodeau, OpenLink

Minutes

API chapter questions

Jon: Let's start with the email I sent titled "Some questions for Ingo (and everyone else)"

(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
error?

Jon: Question (1) is for Ingo and Aptana. Let's go to question (2).

RESOLUTION: Need Ingo/Aptana to respond to this one.

(2) Let's suppose your Ajax library uses a JavaScript class that is located
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).

...discussion...

Stew: Yes, that's my understanding

RESOLUTION: Yes, 'name' is for *definitions* and 'datatype' is for *referencing*

(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?

...discussion...

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
aliased. Correct?

...discussion...

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
in the metadata file, must there be a real JavaScript variable that
implements this alias (e.g.,
io=MyLibrary.shared.crossplatform.communications.io)?

Jon: Bertrand, you are the person on the call who would understand <alias> the best.

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.

Ted: Agree.

RESOLUTION: 'visibility' on <class>, < constructor>, < method>, < property>, < field>, < interface>, < mixin>,

(7) I forgot what <namespace> does. Can someone remind me so I can add text
to the spec?

Bertrand: For when a library defines a namespace, such as the OpenAjax namespace

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.)

InteropFest

...Jon gives outline of InteropFest, which covers both IDE workflows and mashup workflows...

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 reference implementation

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 through.

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 if it can load either the JavaScript APIs or the widgets. So, not much for 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 Metadata if the JavaScript files use JSDoc annotations. But I also want to 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

Localization

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.

Message files

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?

Bertrand: Yes

Jon: Why is it necessary to wrap the text in a <value> element? Seems superfluous.

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

Personal tools