IDE Minutes 2009 03-24

From MemberWiki

Jump to: navigation, search




  • Jon Ferraiolo, IBM
  • Javier Pedemonte, IBM
  • Kin Blas, Adobe
  • Lori Hylan-Cho, Aptana
  • Adam Peller, IBM
  • Javier Pedemonte, IBM
  • Bertrand Le Roy, Microsoft


(1) Gadgets TF says allow substitution on referenced content

* Jon:

Localization substitution:
* <content> (inline and SRC=)
* <javascript> (inline and SRC=)
* <author>
* <description>
* <shortDescription>
* <example>
* <license>
* <remarks>
* <title>
* <aboutMe>
* <quote>

Property substitution:
* <content> (inline and SRC=)
* <javascript> (inline and SRC=)

Widget ID substitution:
* <content> (inline and SRC=)
* <javascript> (inline and SRC=)

Note that we are proposing that there is no substitution for REQUIRE,
PRELOAD or POSTLOAD. (See "Discussion" in email)

One more thing: just wanted to highlight the fact that the IDE spec says
that the SRC attribute is required on the REQUIRE element. That means no
such thing as inline REQUIRE. (I guess that's what the JAVASCRIPT, PRELOAD
and POSTLOAD elements are for.)

RESOLUTION: Above proposal from Gadgets TF is approved

(2) Gadgets TF worries about @@, %%, and __

* Jon:
* Howard:
* Adam:
* Howard:
* Howard:
* Jon:
* Adam:
* Jon:
* Jon:
* Kin:
* Kin:
* Adam:
* Adam:
* Jon:
* Kin:
* Jon;
* Howard:
* Jon:
* Kin:
* Scott:
* Howard:

Main sub-issues:
(a) Adopt __TYPE_ID__ approach across the board for consistency and
    * Kin says changing the syntax after DW shipped kind of bites
    * Howard says ID has to be uppercase. Why?
(b) Do we want non-substituted strings to generate an error?
    * Note that __foo_bar__ is valid for JS variables and IDs
    * Shindig leaves unmatched __foo_bar__ variables in the content
    * Howard points out that some workflows might have multi-step
    * Kin likes @@ because it generates hard-to-ignore errors
(c) What to do about entityencode() and escapequotes()?
    * Adam's proposal: __MSG at ENCODE_foo__ and __MSG at QUOTE_foo__
    * Kin likes: @@foo(bar)@@ because it left the door open for introducing
options in the future
(d) Make 'spec' attribute on WIDGET element a required attribute?

Lori: What is benefit of switching, other than consistency and compatibility?

Jon: Could help developers move to and from OpenSocial gadgets and OpenAjax widgets, but there are several issues there, so that's only a minor benefit

Adam: Would make the rules simpler

Kin: I like having the difference. You can see the differences in the different variables.

Lori: Me, too

Kin: We would be swapping into something more verbose

Kin: Does allow addition of new variable types

Adam: OpenSocial syntax allows for a single regex. Doesn't have the problem of running out of special characters

Lori: Status quo is pretty good

Jon: One way or the other, it's just a few lines of code

Adam: The OpenSocial approach is more elegant. Our approach wouldn't look as good to outside people

Kin: OpenSocial and OpenAjax specs are eerily similar.

Jon: Yes. In fact, we have been purposely moving the OpenAjax specs to align better, with the long-term goal of seeing if we can combine them in the long haul. That's why the Gadgets TF split off the gadgets features and made a bunch of changes. For better alignment.

Kin: Why have different formats?

Jon: Yes, major overlap, but OpenSocial isn't addressing all of the needs for Enterprise mashups, and haven't been responsive about moving in that direction. So, we finish 1.0, and then look to see about some method of merging down the road, either consolidated formats or maybe have Shindig support both OpenSocial Gadgets and OpenAjax widgets.

Adam: Conceivable that people would write tools to support both formats

Kin: What bugs me about the OpenSocial method is that the syntax is legal in JavaScript. False positives. @@ is definitely illegal in JavaScript.

Jon: If we move to merge the formats or merge implementations down the road, it's not that big of a deal to add support for the OpenSocial approach to the OpenAjax approach. Just a few lines of code.

Jon: One more thing to keep in mind. We haven't talked about BIDI yet. OpenSocial has a simple and nice feature for BIDI where there are four strings that you put into CSS, such as __BIDI_START__, which for Roman languages is left-to-right, and for Arabic would be right-to-left, depending on user locale. We might want to adopt that.

Jon: Straw poll

  • Kin: Prefer keep, but on the fence
  • Lori: Same as Kin
  • Adam: Leaning towards common syntax, but I want it to fail
  • Javier: My instinct is towards a common format, but I understand the issue with existing products
  • Bertrand: Same as Javier
  • Jon: Just want a decision

Adam: For BIDI, could simply use the syntax that OpenSocial uses. Therefore, __WID__ and __BIDI_whatever__

Jon: Sounds like no strong opinions, except for wanting a syntax that will fail if substitution doesn't happen, which OpenSocial doesn't do, and generally no strong sentiment to use OpenSocial's syntax. Any objections to keeping what we have?

(no objections)

RESOLUTION: Keep our substitution syntax as is (and no further discussion of the issue)

Jon: Three votes to make 'spec' a required attribute. We already require the 'id' attribute on the same element, so not much extra burden by making this attribute required. Any objections to making 'spec' required?

(no objections)

RESOLUTION: 'spec' is a required attribute

(3) Localization: Don't do runtime merges of localization files

(Jon repeats explanation from first email, such as needing an HTTP request to tell you what localization files are on the server if the runtime agent is supposed to do the merge.)

Kin: I prefer the merged approach, but this proposal seems reasonable for 1.0

Adam: From what I can tell, systems like Java that do the merge didn't have the network issue. This proposal would help to simplify. Other widget specs are all over the place.

Jon: Proposal is not for 1.0, but maybe for a future spec.

RESOLUTION: Don't do runtime merges of localization files

(4) Drop inline message bundles?

Jon: IBM requested this, and now we say we don't need it. Any objections to dropping inline message bundles?

(no objections)

RESOLUTION: Drop inline message bundles

Personal tools