IDE Minutes 2009 03-24
- 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
RESOLUTION: Above proposal from Gadgets TF is approved
(2) Gadgets TF worries about @@, %%, and __
* Jon: http://openajax.org/pipermail/ide/2009q1/001011.html * Howard: http://openajax.org/pipermail/ide/2009q1/001013.html * Adam: http://openajax.org/pipermail/ide/2009q1/001015.html * Howard: http://openajax.org/pipermail/ide/2009q1/001019.html * Howard: http://openajax.org/pipermail/ide/2009q1/001020.html * Jon: http://openajax.org/pipermail/ide/2009q1/001021.html * Adam: http://openajax.org/pipermail/ide/2009q1/001022.html * Jon: http://openajax.org/pipermail/ide/2009q1/001023.html * Jon: http://openajax.org/pipermail/ide/2009q1/001025.html * Kin: http://openajax.org/pipermail/ide/2009q1/001026.html * Kin: http://openajax.org/pipermail/ide/2009q1/001027.html * Adam: http://openajax.org/pipermail/ide/2009q1/001028.html * Adam: http://openajax.org/pipermail/ide/2009q1/001029.html * Jon: http://openajax.org/pipermail/ide/2009q1/001030.html * Kin: http://openajax.org/pipermail/ide/2009q1/001033.html * Jon; http://openajax.org/pipermail/ide/2009q1/001034.html * Howard: http://openajax.org/pipermail/ide/2009q1/001035.html * Jon: http://openajax.org/pipermail/ide/2009q1/001036.html * Kin: http://openajax.org/pipermail/ide/2009q1/001037.html * Scott: http://openajax.org/pipermail/ide/2009q1/001038.html * Howard: http://openajax.org/pipermail/ide/2009q1/001039.html Main sub-issues: (a) Adopt __TYPE_ID__ approach across the board for consistency and compatibility? * 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 substitution * 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
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?
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?
RESOLUTION: 'spec' is a required attribute
(3) Localization: Don't do runtime merges of localization files
- Jon: http://openajax.org/pipermail/ide/2009q1/001031.html
- Kin: http://openajax.org/pipermail/ide/2009q1/001032.html
(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?
RESOLUTION: Drop inline message bundles