[OpenAjaxIDE] Minutes 2008-07-01

Tue Jul 1 14:52:35 PDT 2008

IDE Minutes 2008 07 01

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

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

      http://openajax.org/pipermail/ide/2008q3/000524.html

(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

      http://www.openajax.org/member/wiki/2008_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

      http://openajax.org/pipermail/ide/2008q3/000525.html

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

      http://openajax.org/pipermail/ide/2008q3/000525.html

      http://openajax.org/pipermail/ide/2008q3/000526.html

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080701/ca0eac21/attachment.html 