2008 March Members Meeting Minutes

From MemberWiki

Jump to: navigation, search

Contents

[edit]

Wiki pages for the OpenAjax members meeting of March 21, 2008

The following are the various wiki pages that document the OpenAjax Alliance's members meeting of March 21, 2008:


[edit]

Attendees

[edit]

In person

  1. David Boloker <boloker(at)us.ibm.com> (our host)
  2. Jon Ferraiolo <jferrai(at)us.ibm.com>
  3. Joonas Lehtinen <joonas.lehtinen(at)itmill.com># Olivier Poupeney <opoupeney(at)dreamface-interactive.com>
  4. Howard Weingram <weingram(at)tibco.com>
  5. Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
  6. Yehuda Katz, <wycats(at)gmail.com>, individual
  7. Jean-Marie Chauvet, <jmc(at)dreamface-interactive.com>
  8. Wes Thielke, <wes.thielke(at)mobileaware.com>
  9. Lori Hylan-Cho, <lorihc(at)adobe.com>
  10. Dylan Schiemann, <dylan(at)sitepen.com> (80% chance that I will stop by for a few hours)
  11. Coach Wei, <cwei(at)nexaweb.com>
  12. Slava Frid, <slava.frid(at)gemini-systems.com>
  13. Gideon Lee <glee(at)openspot.com>
  14. Rich Thompson <richt2(at)us.ibm.com>
  15. Marc Perrone <marc.perrone(at)jci.com>
  16. Stew Nickolas <nickolas(at)us.ibm.com>
  17. Mike Pinette <mikep(at)zend.com>
  18. Javier Pedemonte <pedemont(at)us.ibm.com>
  19. Douglas Crockford, Yahoo (invited guest for Runtime TF and IE8 discussion)
[edit]

On phone

  1. Kevin Hakman <khakman(at)aptana.com>
  2. Kin Blas <jblas(at)adobe.com>
  3. Matthias Hertel <mathertel(at)hotmail.com>
  4. Kris Zyp <kris(at)sitepen.com>
  5. Adam Peller <apeller(at)us.ibm.com>
  6. Ted Thibodeau <tthibodeau(at)openlinksw.com>
  7. Alex Russell <alex(at)dojotoolkit.org>
  8. Seshubabu Simhadri <ssimhadri(at)gce2000.com>
  9. multiple people from IE team (during last hour of Runtime TF and IE8 discussion)
[edit]

Minutes

[edit]

Welcome and Introduction

[edit]

Original agenda and slides

[edit]

Runtime Task Force and IE8 Review

[edit]

Original agenda and slides

  • 9:30 - 10:30: IE8 discussion (leader: Coach Wei) - A town hall-like discussion to review the announced features in IE8, with a focus on those features that are likely to benefit the Ajax community. We will ask the attendees to voice opinions about whether some of the new features adequately address the Ajax industry requirements in a particular area. For example, what are the pros and cons of XDomainRequest?
  • 10:45 - 12:30: Runtime Task Force (leader: Coach Wei) - A town hall-like discussion about the proposed process and existing list of features that the Ajax community is asking the browsers to support in future browsers. We will allow non-members to participate in this session. The goal is to take advantage of multiple people in the same room to compare notes and opinions.
[edit]

Discussion

coach: runtime TF intro -

  • started from last face-to-face in oct 2007
  • collected issues with ajax runtime (particularly browser issues)
  • trying to get browser vendors to fix some issues
  • runtime wiki lists total of 29 issues
  • allows non-OA members to comment on issues
  • to join runtime wiki, send email to jon ferraiolo for access

coach: each issue has separate write-up with description and possible solutions

  • at bottom of each issue is a discussion section followed by a feature priority

jon: browser vendors might find this useful

  • to see which issues has a higher priority and what others are saying about this issue
  • might be hard to get OA community to agree on solutions or priority, but browser vendors might be interested

?: will browser vendors come to this site to view issues?

jon: been in contact with a few browser contacts already

  • suggest that we add bugs to their bug databases and link bug report to our wiki entry for backup details

bertrand: now is a good time to get browser vendors involved

?; if one browser adds a feature, others might follow

coach: what's next?

  • need to find way to open this up to general community - the more feedback, the better
  • how do we get community involved
  • might be easier to get people involved if they are allowed to vote up or down an issues
  • idea to send this list to Ajaxian

?: get toolkit blogs to post announcement as well

howard: if we manage through wiki, does that mean we have to grant individual access?

coach: runtime TF wiki separated from rest of OA wiki, so grant access to runtime wiki, but not to rest of OA wiki

?: but that still requires granting access

jon: let's play it by ear, and see who joins

  • think i changed wiki options so a user can create themselves a login without emailing jon directly

<mathertel> you might get million registrations...

ACTION: Jon to make sure individuals can register themselves

rich: do we want to grant access to all of runtime TF wiki, or just the issues pages?

coach: this wiki set up for this particular purpose, so it is fine

jon; when do we want to close version 1?

coach: are we ready to put out list of issues, or do we need more work?

?: might be worthwhile to compare list of issues against what IE8 has already announced, find out which of these issues are still relevant

jon: setting a deadline might help participation

2 months might be short, but maybe around 3 months

gideon: straw poll where OA community picks top 10 of these issues?

jon: milestones over a period of 2-4 months to do several passes of votes on priority. two passes?

<ferraiolo> one milestone at end of April, one milestone at end of May?

?: just put name on 10 that you like

jon: what about putting name and high-med-low priority?

Yehuda: just listing top 5 or 10 would help bubble up significant issues

yehuda: remove priority column from "feature priority" table at bottom of issues and have people add their name to their top 5/10

ACTION Yehuda, Coach or Jon: Remove or disable priority column for pass #1

jon: vote and comment for first pass, priority for 2nd pass

coach: send mail to Ajaxian after 1st or 2nd pass

rich: immediately

announcement should have comment on timeliness - do it now

coach: consensus - send announcement to Ajaxian ASAP - after system is set up

RESOLUTION: ASAP announcement to Ajaxian

ACTION Coach and Jon: Announcement to Ajaxian

when should we start having conversations with browser vendors now? when is right time?

bertrand: as far as MS is concerned, this conversation already exists

jon: they'll see announcement on Ajaxian

coach: separate conversation alongside Ajaxian announcement?

howard: involve them ASAP

jon: already talked to safari team, mozilla is in alliance, along with opera

coach: anything else we should talk about in runtime TF?

(no response)

coach: let's look over features

first 4 are security issues

[edit]

"better security for cross-site scripts"

jon: where did this issue come from?

coach: from doug and joe walker

doug: much wider conversation than just adding a feature to the browser

list of possibilities, i.e. using iframes

problem is iframe isn't a security sandbox

proposed using it since it's the only thing we have

looking at using iframe with JS subset, since neither alone is adequate

coach: would like to see browser impl something new to make them more secure

yehuda: add section for workarounds, in addition to browser solutions

doug: list for what browser should be doing, and a list of workarounds for current gen of browsers

ACTION: COACH or JON - change proposed solution to proposed workarounds

doug: talking about XSS, but current "possible solutions" don't actually address that issue

mashups are intentional XSS hacks, but need better solution

  • slightlyoff has joined #oaa-interop

doug: solution - replace JS and DOM

jon: browsers should offer solution to set something as closed, that would disallow current behavior for pages that don't need XSS

doug: this would break many pages, i.e. loading Dojo from AOL

doug: most dangerous XSS vectors for mashups are ads

get ad industry involved in this discussion

<mathertel> What about a list of trusted sites, that is included in the original download html code - and block all others

<mathertel> can anybody read that loud ?

(sure, hold on)

<slightlyoff> mathertel: well, that doesn't entirely solve it

<ferraiolo> What we are saying is that we should put ideas like that on the runtime wiki and then move on to the other features in the list

jon: put that on wiki, since we need to move on to other subject (to mathertel)

<ferraiolo> Matthias, do you need a runtime wiki login?

<mathertel> yes, just mailed.

<wycats> jhpedemonte: I don't have a runtime account

<wycats> I need one

<wycats> ferraiolo: can you add me?

ACTION JON: Runtime accounts for Matthias and Yehuda

ACTION Matthias, Jon or Coach: Add new topic for restricting cross-site features, such as list of sites that are allowed to be accessed

[edit]

"strong CSRF protection" issue

coach: "strong CSRF protection" issue

suresh: can't really mandate that web app devs create app correctly

<slightlyoff> this security stuff is something of a rathole WRT the agenda

<ferraiolo> Yes, we are trying to move onto the next topic

howard: add boiler-plate under solutions saying that we don't endorse each, but are merely possible solutions

<wycats> slightlyoff: maybe we need a subgroup dealing with security

<slightlyoff> it's like brining up text editors...

doug: virtual sessions using cookies was kludge by Netscape, but cookie RFC never mentions auth

  • no correct way of doing sessions in browsers
  • cookies leaves us vulnerable
  • do we keep adding band-aids on top of band-aids, or come up with correct solutions
  • comet has figured sessions out
  • rather than fix cookies, integrate comet
[edit]

Cross-domain requests

doug: like cross domain stuff that microsoft is doing

  • opposed to HTML5 solution

<slightlyoff> W3C access control isn't terrible....it's only when it gets to the XML brain-damage that it falls over

coach: "cross-domain secure data access" issue

<ferraiolo> Next issue, cross-site access. W3c VS xdr VS JSONRQEUST VS...

<slightlyoff> it becomes incredibly hard to reason about because the PI's aren't processed in order, etc.

<wycats> wasn't there an agenda item under the IE topic for this?

coach: JSONRequest from doug, XDR from MS

coach: cross-domain using CSS

<slightlyoff> as a group we need to insist on a subset

gideon: i abandoned that solution, opens up more issues than it solves

<slightlyoff> we need to be able to send one request that can work with everything that's deployed

<slightlyoff> no matter how many slightly overlapping specs have been deployed

suresh: agree with doug, IE solution is good from security standpoint

<ferraiolo> Votes in favor of MS's approach: Doug, Yehuda, Suresh from IBM's security team. Also Jon

bertrand: XDR for starting with locked down app and opening up as needed

<wycats> slightlyoff: do you disagree with MS?

<wycats> trying to get the MS approach to be adopted by other browsers?

<ferraiolo> alex has some concerns about w3c and says MS's proposal is fine

<ferraiolo> alex doesn't like content delivering processing instruction for security and that's terrible

alex: fine with w3c access controls if dropped XML; IE solution is fine; need to take one proposal to browser vendors

<slightlyoff> yes, very aware

jon: access controls can be done with headers

<ferraiolo> should say that doug prefers jsonrequest but xdr is acceptable

kris: agree with alex about XML processing, w3c uses sessions cookies (?) whereas IE solution doesn't

kris: post can be sent without auth, response must be authed

concern about what API looks like in JS

IE has diff constructor

<ferraiolo> kris points out that there is some discussion at w3c where some people say Ms's approach in some ways is less secure than W3C approach

prefers XHR

<ferraiolo> Kris prefers building on xhr versus new thing, but it's an orthogonal issue

prefers XHR over introducing a new constructor, that is

Coach: Summary; IE8 solution appears ok, but there is some preference for tweaks to the proposal

<slightlyoff> agreed

<slightlyoff> it is nicer

Doug: Note that the new API is much nicer than the existing XHR

Coach: Continuing summary; more issues with the W3C approach

(Jon adds this note: there was consensus among attendees, not unanimity, that XDR is better than W3C/AC, with some people preferring XDR's for security reasons, others preferring XDR for simplicity reasons. Call to action on other browsers to implement XDR.)

<ferraiolo> BREAK OVER, BACK TO WORK

[edit]

Mashup Security

Coach: Moving to the Mashup Security issue

Yahuda: Noting that we may want to summarize the various security items and how these different items overlap and combine to define the need overall approach

<wycats> perhaps in a subcategory called "security"

<wycats> it might even make sense to have a sub-task-force or something

Suresh/Coach: Will this be naturally solved if the other security items are solved?

Jon: We probably should drop if there aren't additional requirements

ACTION Coach or Jon: Consider dropping mashup security issue

Noting that Hub 1.1 addresses the issue through the top level controller implementing whatever the page source has specified

It does need a faster means of sending a message across the IFrame boundary ...

<slightlyoff> that messaging is also available in FF 2 and FF3 via DOM storage events

<ferraiolo> Alex, thanks, I hadn't noticed the dom storage events

ACTION: Jon or Coach - add notes about storage events to this feature

[edit]

2 connection limit

Coach: Next item is the 2 connection limit

<slightlyoff> it's not solved by the 6 connections

Yahuda: IE8 raises this to 6, with an option to request raising it further

<slightlyoff> the use-case we care about is Comet

<wycats> slightlyoff: indeed thx

<slightlyoff> and that just buys you 5 tabs

Alex: IE8's approach helps. Would prefer the developer specifying common vs private connections with only the common ones counting against the limit

<ferraiolo> Rich, it's comet, not common

<ferraiolo> Comet is the ajax technique for simulating server push

I thought he was making a broader comment with comet as an example

<ferraiolo> I think it's mainly about comet. I can explain later why.

ok

Coach: Noting that a large number of connections can be a problem for mobile

<slightlyoff> there are online/offline events

<slightlyoff> but those aren't "right' either

Howard: Also need a common means of detecting that you have maxed out on connections

<slightlyoff> those only tell you if the network connection is down...not if the *service* you're talking to is unavailalb

Howard: Comet is a particular communication paradigm, but others exist ... it should not be treated as a single special case.

<ferraiolo> discussion that there are other scenarios than comet for long-lived connections

Alex: Bumping up the connections will also impact servers, which often aren't designed for such an increase in connections

Alex: Key is long-lived connections vs "normal" ones

<wycats> IE8 does detect mobile

<wycats> it only increases to 6 if using broadband

Jon: Everyone should add such comments on the wiki so we can move forward

[edit]

Cross frame communications support

Coach: Next is "Cross Frame Communications Support"

IE8 adds an ability to post cross-frame message, firefox 3 also implements this

<ferraiolo> postMessage in FF3 and IE8 (and Opera?)

<slightlyoff> as does Opera

<slightlyoff> we can emulate on IE w/ timers and userData

<slightlyoff> (assuming data size is small)

Doug: Also noting that the related issues may apply from a single domain

<ferraiolo> doug suggests some additional security controls on iframes such as preventing moving and resizing and controlling ability to communicate across iframes even if from same domain

Example is multiple Yahoo widgets with a need to restrict some of them

<ferraiolo> discussion of how many iframes you can use on a reasonable basis

Various people noting that 30+ iFrames can have a signiificant performance impact

<ferraiolo> sumeer says it works ok for about 30 in their tests

Coach proposes adding a new feature for desired IFrame improvements

ACTION: Coach/Jon new feature for IFrame improvements

<ferraiolo> gideon says wants ui events to propagate across iframes

also, develoeprs control over how heavy weight the frame is

<ferraiolo> gideon also says also wants to have lightweight vs heavyweight versions

<ferraiolo> people note that <module> is one proposal for lightweight iframes.

<ferraiolo> doug says attributes on iframe can achieve same result as <module>

<ferraiolo> doug suggests it should also work for framesets

[edit]

Event transparency

Coach: Next item is Event Tranparency

Alex: This is about differentiating the logical z-order from the visual one

The important use cases don't need maintaining a different order, at lest being able to make the event ignore the top layer

[edit]

Mutation events

Coach: Next is for browser support of the DOM mutation evetns

Jon: Would be very useful iff they are implemented everywhere

Bertrand: Also an issue for screen readers ... IE8 is adding them for this use case, should be easy to open to javascript as well

[edit]

Array and DOM performance

Coach: next is Array performance, but we will skip it

Coach: next is DOM performance

<slightlyoff> once querySelectorAll is in, our next bottleneck is positioning information

Bertrand: It appears the next versions of the major browsers will all have fast selector support

<slightlyoff> positioning!

ACTION: Coach or Jon add feature about positioning

Yehuda: Fast conversion of a string into html would also help

[edit]

Computed box model

Coach: next is Computed box model

Bertrand: it also appears the major browsers are all on track to have this, but need a single API

<slightlyoff> ugg

Alex: Need other properties of the box model as well ...

Jon: What about getComputedStyle, etc

Consensus appears to be these are also important

Bertrand: spec can be found here: http://www.w3.org/TR/cssom-view/

ACTION: Coach or Jon make sure that above is captured in feature list

[edit]

String performance in IE

Coach: Next is string performance in IE

<ferraiolo> discussion at w3c about doing something different than CSS DOM getComputedStyle

Betrand: Note that IE8 is much better

<slightlyoff> well, it's getting closer to FF/Safari ;-)

Bertrand: For example string concatenation is now faster than array.join

[edit]

Firefox performance issues

Coach: next is Firefox performance issues ... look like they are resolved in FF3

[edit]

IE array subclassing

Coach: next is IE array subclassing

<slightlyoff> it's IE specific

Yehuda: basically this is a bug that needs to be addressed

<slightlyoff> not fixed in IE 8

<slightlyoff> (yet)

Bertrand: Please check on IE8, enter a bug if it isn't fixed

[edit]

Client-side storage

Coach: next is increase client side storage

<slightlyoff> max 100 meg total

<slightlyoff> (in IE 8 b1)

IE8 allows 10MB, with ability to request more

<slightlyoff> that's like Flash's policy

<slightlyoff> (where it prompts)

Bertrand: user has to acknowledge any requests beyond the basic 10MB/100MB limits

[edit]

XPath

Coach: next is XPath support

Yehuda: this is less important if you have good querySelector support

Howard: May stay important as more sites begin to use XML ...

[edit]

2D Graphics

Coach: next is 2D graphic support

all browsers have some support, but all inconsistent

<slightlyoff> VML is soooo sloooow

<slightlyoff> and buggy as hell

?: VMl appears to be getting worse as IE versions move forward ...

<wycats> hehe

Coach: We want to encourage all browser to support SVG

Bertrand: There is an SVG plugin for IE ... it is from Adobe* Suresh has joined #oaa-interop

?: noted that the support is far different than the other browsers* comments on contrasting with Silverlight ...

coach: key is we want uniform SVG support

<mathertel> adobe has dropped support for it

<slightlyoff> IE 8's VML is terrible and/or broken

Noted that a community effort to build an SVG plugin could solve the conflict of interest issues for Microsoft and Adobe

<ferraiolo> One more thing from vector graphics topic is that Coach said that plugins aren't sufficient we need vector graphics as a native feature

[edit]

JavaScript performance

Coach: next is Javascript performance

  • noted that this impacted by many things, some of which are noted in other items

<slightlyoff> time on the wire!

[edit]

Ajax features

coach: next is a placeholder for AJAX features

ACTION Coach or Jon: remove this item?

[edit]

Scoped IDs

Coach: next is client side scoping of ids

Bertrand: This is need for good template support

Options are scoping the ids and generating unique ones

<slightlyoff> how about XBL?

<slightlyoff> or fixing HTC?

<slightlyoff> those would solve it = )

<mathertel> We need a "unique" identity for objects -> that's id; other implementations should use className or name and that works already.

Yehuda: Questions whether this needs to be specific to the id attribute ... perhaps using querySelector instead

<slightlyoff> lets drop it?

<mathertel> yes

<ferraiolo> thinking on the floor is that we modify it to talk about other approaches leveraging css query apis

Betrand: Perhaps we can publish a best practices rather than a requested browser feature

ACTION Coach or Jon: Consider putting scoped IDs into discarded area

[edit]

Client element hash

Coach: next is client element hash

Bertrand: Key is associating data to an element

<slightlyoff> in Dojo, we wrap the element in an object

Can be done with expnders (needs cleanup), wrapper objects or hash based references (or equivalent)

<slightlyoff> and then deal with that

<slightlyoff> but these are all proxies for true component systems

<slightlyoff> (aka, HTC or XBL)

Howard: Key as modifications of core objects often become problematic

Jon: Would the AJAX community adopt an XBL approach if it was uniformly implemented?

<slightlyoff> our view is that we can't use HTC/XBL today becaues the differences in the way you declare things (combined w/ IE bugs) makes it unworkable

<mathertel> It can be done by using javascript only; search "JavaScript Behaviors"

<mathertel> every toolkit does it in its own way

Conversations appear to this would be a big change

<slightlyoff> well, current toolkits shouldn't define the future

<ferraiolo> alex, yes, agreed

Bertrand: Most browser vendors would probably be quite willing to drop proprietary approaches for a well accepted std

[edit]

onoverflow

Coach: next is onOverFlowChange event

This causes a performance issue for some toolkits

<ferraiolo> dylan says not top priority but if there they would use it

Yehuda: even just receiving this on other events would help

<slightlyoff> yeah, good positioning in general is more important

<ferraiolo> NOTE TO JON AND COACH: make sure there is an item for css positioning

gideon: an ability to request sizing before inserting into the DOM could also be quite helpful

<slightlyoff> flexbox +1

dylan: core issue is that CSS is a poor layout language ... wasn't designed for that

As a result, most toolkits have to reimplement layout ...

<ferraiolo> NOTE TO JON AND COACH: add item for better layout features within browser css engines

[edit]

Bleed through

Coach: next is Bleed through problem

Yehuda: Fixed in FF3 and IE7; not known to exist as a bug elsewhere

Coach: next is IE overflow ... was noted to be unique to IE6 & 7, but appears at most to be a bug

[edit]

z-index control

Coach: next is z-index control

Bertrand: also appears to be at most an IE rendering bug

Jon: perhaps we should segregate issues which appear to already be in the process of being addressed

ACTION Coach or Jon: Consider having a separate group of features that are in the process of being addressed

[edit]

Toolkit caching

Coach: next is toolkit caching

dylan: toolkits which are shared, but sourced from unique domains

Howard: Would need to be careful about security issues ...

Rich: Is this specific to browser caching?

Coach: maybe, but it is a big issue with AJAX toolkits and they might be able to solve it quicker

Doug: perhaps an additional attribute on the script tag (hash?) used for security and versioning issues

Jon: We should have a related feature request related to off-lining pages (ala Goole gears)

<slightlyoff> Prism is also doing work in this area

<ferraiolo> NOTE TO JON AND COACH: Add item for offline

<slightlyoff> but we need events

Coach: the hash idea could solve this and related ideas

[edit]

Rich Text Editing

coach: next Rich Text Editing

Consistency is the issue

Bertrand: In general the undo stacks are useless ...

Howard: This appears nice to have, but doesn't address the brokenness of some of the others

Yehuda: But it would be easy for browser vendors to get together and address this

<slightlyoff> well, consistency and Undo

<wycats> right

<wycats> there needs to be a spec

<wycats> that's the fundamental issue

<slightlyoff> agreed

<wycats> no clear direction on what browsers are supposed to do

[edit]

Better testing support

Coach: next issue is Better testing support

<slightlyoff> we also need to be able to generate events more reliably

<slightlyoff> that stymies lots of automated testing

Yehuda: FF now has testing against browser-based apps as part of their cycle

Coach: Toolkits could publish test suites against their systems

Howard: Automating interactions becomes the means to work through app test suites for toolkits

<slightlyoff> is there a particular feature that's being requested here?

Yehuda: While IE has this natively, it is possible in all browsers, but buying 3rd party software is often required

[edit]

CSS Object Model

Coach: next is CSS Object Model

<wycats> it's possible that OSS alternatives exist, but I have not seen them

Jon: This is the broader request related to the getComputedBox feature/discussion

[edit]

Wrapup and next steps

Coach: Next step is cleaning things up on the 29 issues

Timeline is the next couple of weeks

Jon to make it easy for user to register themselves

<wycats> hear hear

Then we will publish request for people to come and participate in the strawpoll

All should enter details they know into the item pages in the wiki

[edit]

IE8 discussion

Switching to the IE8 agenda topic

<slightlyoff> are any of them on IRC?

IE8 team members joining - Mark Silby (+ most of team working on AJAX support)

<slightlyoff> don't care

Announce URL: http://www.micorsoft.com/windows/products/winfamily/ie/ie8/readiness/DevelopersNew.htm

Jon: Let's go through this document from bottom to top since topmost items, activities and slices, probably don't relate to this discussion. Need to go quickly due to time constraints.

[edit]

XML namespace support

<slightlyoff> (about the XML ns issue)

Jon: Do people care that IE8 adds support for namespaces that doesn't quite match other browser support or the W3C's specs?

<mathertel> typo in the url !

Yehuda: It would be good to know an IE9 is planned ...

<mathertel> should be: http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/DevelopersNew.htm

sry & thanks

IE8 team thinks so, but they aren't the decision makers ... it is unlikely to stop at IE8

<wycats> they say they can "comfortably say" that there will be an IE9

<slightlyoff> thank you *very much*

Jon: summary; namespace support issue doesn't light a fire in the AJAX community

[edit]

Acid2

Yehuda: Wonder why the IE8 beta doesn't claim passing ACID2

<slightlyoff> huzzah!

Beta 2 passes ...

<slightlyoff> RichThompson: Beta 1 passes

[edit]

Memory fixes, performance fixes, selectors, DOM Core

Jon: fixing memory leaks and improving performance is always good

Jon: All glad to see selector API and improvements in the DOM core

<slightlyoff> SVG/VML?

[edit]

6 connections

<slightlyoff> and can we outline the 6-connection thing?

Jon: we are glad to see increase in connections

Doug: reviewing request to turn off access even for things from the same domain ... and allow them for certain cross domain sets

Perhaps as an extra attribute on IFrames

(Jon: there was unminuted discussion about a flag on a connection to identify as long-lived)

[edit]

Ajax navigation

<mathertel> Regarding AJAX Navigation topic:

<mathertel> When changing the hash if the current url IE8 will push this change onto the browser history stack to make it available through the back button.

<mathertel> I am concerned about the fact that this is not the only scenario why hash values are changed by scriting.

<mathertel> The other one is to give the user an always

<mathertel> but without disabling the back-button for navigationg back to the latest (other) web page.

<mathertel> I see conflicts arising:

<mathertel> 1. when using several OpenAjax sources in one page the overall behavior is not clear.

<mathertel> 3. bring in more browser specific code

[edit]

XDR and postmessage

Jon: We talked about these earlier. The consensus was we prefer XDR over W3C because of security concerns and prefer the simplicity, and call on other browsers to implement XDR. We are happy that you have implemented postMessage.

[edit]

Ajax navigation, 6 connections, iFrames, XHR improvements, long-lived connections

Locking down to XDM communication is the core need

<slightlyoff> breaking SMASH is fine = )

<slightlyoff> (if we get something better)

Note that this would replace smash and break use of it

Jon: Many in the room think other browser vendors should implement the XDR approach

Jon: XHR improvements are good; 6 connections help ... long-lived as a separate category would also be good

<slightlyoff> dissenting on the connectivity events!

Jon: IE8 does HTML5 style of DOM storage? (answer = yes)

Alex: Could the browser implement automatically going off-line if connectivity breaks?

<slightlyoff> +1

Jon: AJAX navigational is a good thing

?: note that some aspects of this could break existing applications related to the back button

Howard: IFrame sandboxing request ... can we suppress cookies from the parent domain?

(^ I think "?" was mathertel, who added text above)

Question asked about interest in turning off scripting in a child IFrame ... noted that this isn't interesting in an AJAX world

[edit]

Meta tag

Jon: meta tag to go out of stds mode and back into compatibility mode

dylan: noting that the IE7 mode isn't quite IE7

IE8 team: Would like to know any deltas as these are bugs!

<slightlyoff> we're all incredibly opportunistic = )

Also noted that the additional functionality will still be available; security improvements are likely to not be considered bugs ...

Request to have the user agent identification identify both the browser and the rendering in use for the page

<slightlyoff> HTC's should work from data URI's

<slightlyoff> (so we don't have to go to the network for htem)

<slightlyoff> ...that's cause it started at like 6am on this coast ;-)

<slightlyoff> ok, need to go

[edit]

Wrapup and discussion

Coach summarized the plan for moving forward with the issue/feature request list

Question about timeline that would matter for the IE8 team

IE8 team: The next couple of months matter for making it into IE8, but a followon release after IE8 is also expected for anything that runs later

Resolution: Announcement to Ajaxian ASAP, April for 1st pass review without priority field where people select their top <n> favorites, May for cleanup and more discussion with browser teams, June for 2nd pass review with voting, then publish version 1

[edit]

OpenAjax Hub 1.1 and Metadata

[edit]

Original agenda

[edit]

Discussion

jon: start talking about Hub 1.1

yehuda: we shouldn't be using minor version numbers like this, and instead go to "Hub 2" for naming

ACTION Jon to start discussion about calling it Hub 2

(Jon gives overview of widget mashup)

  • individual widgets talk to backend servers
  • really interesting part is when widgets talk to each other
  • The mashup application, the container, relies on Hub 1.1
  • The gadget/widget is described by the metadata (metadata can be used by both the Hub and by IDEs)
  • Open-source transcoders that help developers convert from custom metatdata to OA metadata

jon: secure mashup arch - hub 1.1 loads a messaging hub, metadata spec is for describing a widget/gadget

mashup arch supports technique for writing adapters for existing widget/gadget specs

hub 1.1 intended to be commercial grade

min-mashup app (on OA SVN) is a demo app - not intended for commercial use

metadata spec defines gadgets so that they can be used by mashup IDEs

Q: What would IDEs do with the metadata?

Jon/Lori: Depends on the IDE, but among the options: property dialogs/inspectors, code hinting/code assist, wysiwyg rendering, asset management

<wycats> Does Microsoft have a trademark on the term gadget?

jon: hub 1.0 did pub/sub within a single frame

hub 1.0 is insecure - everyone can talk to everyone else

hub 1.1 allows pub/sub across isolated components (i.e. iframes)

also allows client-server communication

(Sumeer explains insecure server-side mashups, client-side mashups)

  • SMash = secure mashups
    • enforcement of component boundardies
    • enabling communication between frames
    • performance isn't great, but adequate for mashups that are exchanging small amounts of data
    • will be the backup approach as browsers evolve

sumeer: secure mashups -> policy hooks, auth, integrity of communication

SMash is piece of hub 1.1 impl

smash provides secure component model for building mashups

smash allows different low-level communication protocols - currently uses window.location fragment identifier

smash provides integrity of communication; addresses frame phishing

performance is adequate for low-bandwidth communication

when new browsers support better communication protocol, smash's fragment comm used as fallback for older browsers

now on to hub 1.1

(Sumeer explains Hub 1.1)

  • can have multiple managed Hub instances within one window
  • clients for hub can be in other frames
  • fine-grained policy hooks (mediation between incompatible clients, for example)

hub 1.1 allows multiple hub instances

allows segregation of communication

manager of each hub instance has access to policy hooks

policy callbacks for pub & sub calls - allow or deny call to go through

howard: do as little in hub, and let mashup app define policy. I would like to have a list of subscriptions

Yehuda: I am in favor of having a basic set of defaults that work in most cases; this would encourage adoption.

Jon: I agree we should show them the way (and one way to do this is with a set of defaults). We need to have some guidelines of when/how to let messages go through. One approach is that by default, nothing goes through. We need at least ONE example that works

Dylan: I think providing examples is different than having defaults.

Yehuda: I want examples more than defaults too. New users shouldn't have to read white papers to figure out how to use.

jon: one approach is to not allow any event, but allow user to say that one topic can go from one certain widget to another

gideon: how does this work for nested mashups? who sets policy for nested mashup?

howard: policy is set at level that widgets are handled/managed

howard: for composite gadget, that gadget defines its external wiring, but doesn't expose internal wiring

gideon: could policy be delegated to a component, so a user could set policy for mashup, rather than mashup app?

howard: let's try to keep hub 1.1 as simple as possible (already complex as is), and not add another API/layer to exisiting spec

jon: hub 1.1 allows diff communication providers

smash is just one provider, which uses fragment communication

an inline provider allows communication between gadgets in same frame

can create more comm providers (such as HTML5 postMessage or MS XDR)

^ not XDR, but cross-document messageing

jon: (describing hub 1.1 steps from slide)

sumeer: (showing demo app)

(showing mashup app demo that has several gadgets, two of which are in the same domain and trusted and using the inline comm-provider; and two gadgets that are untrusted and sandboxed in an iframe and using the smash-provider for hub 1.1

david: note that this is Stew's gadgets demo

javier: this specific demo is not available, but the mashup app demo is available on the openajaxallianc.org SVN repository

the demo is hacked to use hub 1.1, but the mashup app demo on SVN still uses hub 1.0

will soon be updated to use hub 1.1

sumeer: (showing demo and how gadgets can communicate using inline and smash providers)

yehuda: hub 1.1 ref impl shouldn't depend on hub 1.0 ref impl - should be able to work on top of any hub 1.0 impl

jon: not possible because hub 1.1 needs openajax.hub.connect which isn't in hub 1.0. But we could say that there is a hub 1.1 core that is slightly bigger than hub 1.0 and that any implementation of hub 1.1 mashup logic should work with any version of hub 1.1 core

howard: let's be careful about adding more complexity to hub 1.0

let's take a look at current source before deciding on this

<wycats> I think the summary of what I said more articulately said what I meant than what I said ;)

Gideon: Compound mashups? Which level sets the policy?

Howard: You could have different policies at different levels.

Gideon: There might be some situations in which you'd want a "God" policy manager that controls everything in the page.

Jon: The Steve Jobs model.

Yeshuda: So you have a mashup that could be included by someone else.

Gideon: Yes, and I want them to set the policy.

Howard draws a diagram (see photo).

Gideon: could policy decision be a component? Instead of hard-wiring the policy into the Hub....

Howard: No, it's a series of callbacks.

NOTE: Abstraction boundaries are very important.

Rich: These are the two use cases: the composite, in which you want the overarching control; and the other is a simple container. I think we've achieved both sets of use cases in a very straightforward way.

Jon: There are multiple providers; SMash is one that will work in existing browsers; inline is another provider we created for trusted widgets; and we're hoping for postMessage to be a provider in HTML5.

Hub 1.1: the steps:

Go to URL that creates the mashup container, which initializes and creates a "Managed Hub". Next we load the widgets inside the container. Each widget has its own Hub. One of the widgets subscribes to a topic and registered a callback function using connHandle.subscribe() Something about the blue blood becoming re-oxygenated and red again and getting back to the widget so that the callback is invoked.

Demo from Sumeer (actually Stew's demo)

david: visited 4 different customers about OpenAjax gadgets work, most loved what they saw

will write this up and send out

ACTION: David to write up what was learned from customer visits

Timeline:

  • Spring 2008: stable, complete spec
  • July-Sept 2008: InteropFest (with OpenAjax metadata)
  • Fall 2008: Finalize and approve

Note: We might be able to move faster!

[edit]

OpenAjax Metadata

(Kevin goes through his slide deck)

Enable the interoperation of the diversity of Ajax:

  • Libraries
  • Controls
  • Gadgets
  • JavaScript objects

...with IDEs & Live Mashups

We're aiming for wide adoption (and soon)

  • Do not force IDEs to change internal formats
  • Do not force Ajax Libraries to change internal formats

"EDIs for IDEs" [much laughter]

Two different styles:

  • markup + CSS + code snippets
  • JS object APIs

"Intermediary" metatdata means

  • Ajax libraries can generate standard metadata from their custom schemes
  • IDEs can consume standard metatdata and transform it into their custom schemes

Coach: can you be more specific about what Dojo's up to (you mentioned that)?

Kevin: Dojo has created a scriptdoc derivative to document their code using the OA metadata keywords

????: Is there going to be a DTD to validate against?

Kevin: Yes, we'll get to that in a minute.

  • Assure compatibility with leading IDEs' metadata schemes
  • Assure compatibility with JSDoc, scriptdoc
  • Produce metadata that can be transformed to and from XML/JSON
  • Because JSON doesn't have support for full schemas, restrict ourselves to a subset of XML schemas that parallel JSON
  • Provide an open source utility for converting between the two
  • data should be human readable.

kevin: overlap in ajax runtimes

objective to enable interoperability between different ajax/JS runtimes

try to get wide adoption soon

try not to force ajax libs to change internal structures

current strategies - code snippets, JS APIs (getter/setters)

^ scratch "current"

impl both strategies

already seeing evidence of some libraries implementing these strategies

standard not finalized, but work on-going

good participation from IDE and tools vendors

dojo has taken JS object API strategy - revamped annotations and doc-generation code

yehuda: are we going to have a DTD to validate against

kevin: yes - come back to that later

did survey of IDEs and assure compatibility

^ for metadata strategy

looked at annotation schemes - JSDoc and ScriptDoc - and assured compatibility

coordinating with Stew and gadgets WG

lots of debate on DTD

whatever format could exist in both XML and JSON

<wycats> +1

<wycats> +1 to JSON that is

kevin: currently using XML, but should be easy to go to JSON

provide utility for that translation

XML should be human readable

^ XML schema

mid-way through work

in position to get draft spec out by early summer, and go through community feedback by end of summer

Estimate completion of specification by end of Summer 2008

  • Very active participation from IDE vendors (Adobe, Aptana, Eclipse/IBM ATF, Mirosoft, Sun) and toolkit vendors (jMaki, ASP.NET Ajax controls, Dojo, OAT, Spry,

and Jon proxying for Yahoo!, Google, Ext, jQuery, and prototype through research).

Hopeful that when toolkit vendors update their libraries, they also update their metadata.

active participation from leading IDE and tools vendors

jon: stew has done coding on gadgets side for existing toolkits like YUI, and gotten them to work with the gadgets demo

wraps widgets from dojo, ext, yui, apple dashboard, google gadgets

kevin: wrapping was manual, but should be automatic

jon: actually, have to manually write automatic wrapper!

wrote adapter for a given class of widget, rather than on each individual widget

kevin: trying to provide incentive for toolkit devs to write OA gadgets layer, through automatic utilities

chose to persue snippet metadata first, and get back to API metadata

API metadata defines several top level concepts (class, global, mixin, interface)

WG meeting once a week, rather than once every two weeks, in order to get this done as soon as possible

market adoption might take a while

jon: interop event for metadata spec? worked for hub 1.0

kevin: demonstrate transcoding from one format to intermediary format, vice versa

yehuda: repository for transcoders

jon: yes, have open source area for open-source-able transcoders

kevin: can link to others

jon: timeline - hub stuff is further along than metadata and IDE stuff

Yehuda: Something about globals

Kevin: We've been looking at the overlap between snippet metadata vs. API metadata, and when we got to the API data, we had the idea that our top level would be class. Then we realized that globals were in widespread use, so we created a parallel object called "global"... and then we realized that there were also mixins and interfaces. So now we have all four -- class, mixin, interface, globals -- as top-level concepts.

Yeshuda: Maybe we need a concept of "registered" or ("included"? "approved"? didn't hear) globals.

Kevin: That's probably right.

Success is measured by the "duh" factor. That is, when the community -- producers and consumers -- all say "duh, of course, it's so simple; why did it take so long?"

Jon: Next step after specification is to have an Interoperability Event.

Kevin: One way to do the Interoperability Event is to focus on the transcoding.

[edit]

OpenAjax Registry and OpenAjax Conformance

jon: (starting talk on OA registry)

had email discussion on closing off registry issues - mostly everyone in agreement

does anyone disagree?

on email, decided not to do "conformance declarations on per-spec basis"

just say 'conformant on the 1 level', or 'conformant on level 2', etc

<kin> Are you guys dialed in to ready conference?

( dialing in now)

jon: conformance on different products (i.e. "conformant on OpenAjax 1 (libraries)", etc

david: we'll have too many compliance products, should just be simply "OpenAjax comformant"

jon: we'll just have one logo for all

yehuda said logo should only be for fully conformant code

yehuda: will we require hub 1.1 as part of level conformance?

does hub 1.1 add anything new that requires you to be conformant?

jon: for libraries, no

for a mashup tool, probably

howard: if you're trying to do communication, then yes

yehuda: if you have two bits of code (libraries) with the logo (i.e. conformant) they should be able to coexist on the same page

ACTION: look into spec saying that a library must be registered when loaded - Yehuda asked if jquery could register when loading a plugin

The Registry conformance statement about documenting potential conflicts needs to be extending to include requiring these to be registered with the Registry as acknowledged entries

Missing registry entries should be treated as supplying an empty array

Extend attributes syntax to include namespace, attributeName and attributeValue (e.g. html:div@fooType=fooVa lue)

yehuda: use CSS selector syntax, already have parsers

howard: some libs won't do CSS, so might not have a parser

yehuda: we can just write few lines for parser for those that don't have one

jon: this is syntax that devs are used to

<kin> How would one represen t namespaced attributes? For example Spry has namespaced attributes, but no namespaced tags. These namespaced attribute s can go on any tag in the document.

gideon: want to reserve a range of ID prefixes

yehuda: yes, should be able to do that

rich: with this syntax, can now get rid of separate registry entries, and just have "items_to_approve" and "items_to_acknowledge"

yehuda: what about this -- 

to_approve: {
  markups:
  globals:
},
to_acknowledg
e: {
  ...
}

(no objections)

howard: might want to recomment if you have a global name, have a prefix (i.e. "dojo"... or "jquery"...)

rich: isn't there a best-practices document that recommends putting classes, etc in a few globals?

jon: yes, in registry white paper

Retrieved from "http://www.openajaxalliance.org/member/wiki/2008_March_Members_Meeting_Minutes"
Personal tools