WebApps had an informal un-conference style gathering in Lyon on November 1. The "notes" from that gathering are available at the following and copied below:

http://www.w3.org/2010/11/01-webapps-minutes.html

-Art Barstow

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                          WebApps F2F meeting

01 Nov 2010

   See also: [2]IRC log

      [2] http://www.w3.org/2010/11/01-webapps-irc

Attendees

   Present
          Adrian, Sam, Maciej, PLH, Bryan, DaveR, AnnB, AdamB,
          timeless, WonsukLee, Eliot, Bryan_Sullivan, chaals, Rishida,
          Aron, DanA, LarryM, Ashok, Aharon, Art_Barstow, Mike_Smith,
          Wonsuk_Lee, zhang_chengyan, wujing, junliao, Johnson_Wang,
          Adam_Boyet, Bo_Chen, Hiro_I, Yung_Yu_Chan, Doug_Schepers,
          Josh_Soref, Eric_Uhrane, Laszlo_Gombos, Yael_Aharon

   Regrets
   Chair
          ArtB

   Scribe
          dsr, timeless_mbp, chaals

Contents

     * [3]Topics
         1. [4]WebIDL and TC39
         2. [5]Web Sockets
         3. [6]Introductions
         4. [7]Web Workers
         5. [8]Programmable Cache
         6. [9]Selectors API
         7. [10]XBL2
         8. [11]Clipboard
         9. [12]WebSQL
        10. [13]XHR + Widgets
        11. [14]Web Events
        12. [15]CORS and UMP
        13. [16]i18n
        14. [17]DOM 3 Events Input Locale
     * [18]Summary of Action Items
     _________________________________________________________

   <ArtB>  ScribeNick: ArtB

   Date: 1 November 2010

WebIDL and TC39

   Adrian: part of the next TC39 meeting (in ~2week) will include
   discussions with some people in WebApps
   ... there is a perception that the other group is not interested in
   working together
   ... for example TC39 people seem to think W3C people is not
   interested in working with them
   ... and within WebApps, there seems to some disinterest in working
   with TC39
   ... there are some tactical issues in the WebIDL spec that need to
   be resolved
   ... see f.ex. public-script-coord
   ... Need to talk about how to work together at a Strategic level
   ... We need to prioritize the work in both groups
   ... so there is better coordination
   ... For instance adding features need to be discussed
   ... The 2 groups have different timelines and there is a gap there
   that needs to be filled
   ... WebIDL is the key spec that has interest from both sides
   ... Microsoft people in TC39 have some issues with the structure of
   WebIDL spec
   ... Some parts of WebIDL may want to be deprecated
   ... f.ex. we don't want some old patterns continued
   ... Think we are talking passed each other a bit
   ... PLH has been involved in conversations with TC39 Chair

   PLH: when I asked 6 mos ago if any WG wants to meet with TC39, no
   one responded
   ... Cam will be at TC39 meeting in two weeks
   ... Are there any other specs TC39 cares about?

   Adrian: WebIDl is certainly the key spec
   ... but there are some other specs

   <anne>  wait what, there's a WebApps WG meeting after all?

   Adrian: The TC heard there were no other specs
   ... I don't think there is fault or blame here
   ... I just think there is a need for closer collaboration

   <anne>  mjs, k thanks

   Adrian: Think there should be a more formal relationship
   ... We all have the responsibility to raise the issues
   ... As ES5 progresses, and more and more APIs @ W3C are written, I
   think there will be more collaboration that will be needed
   ... We must make sure ES and W3C APIs work well together
   ... Don't want a bunch of ad hoc APIS
   ... as that may create some interop probs
   ... Not sure how we fix the perception that neither group is
   interested in working with the other

   Maciej: one thing we can do is to have some coord calls
   ... can also have someone participate in both groups
   ... and make sure they are talking to both groups
   ... There can be issues where two people from the same company may
   disagree

   PLH: so far, WebIDL is the key spec
   ... Good news there is that Cam is back and he will be attending
   TC39 meeting at Apple in 2 weeks
   ... We do meet every couple of months with IETF with a specific
   agenda
   ... But if there is a need to talk about a specific issue, then
   that's different

   Adrian: the joint meeting is in a couple of weeks

   PLH: do we need to send a W3C staff member to the TC39 meeting?

   Adrian: no, I don't think that is necessary
   ... but I think the meeting should include a discussion about
   liaisions and next steps

   PLH: I can attend remotely
   ... will their be a phone?

   Maciej: yes, I think that can be arranged

   AB: that sounds like a good first step
   ... Is Chaals attending
   ... has WebApps been invited to the meeting?

   Adrian: yes, I think WebApps was invited to the coordination part of
   the meeting

   PLH: I will send e-mail John re the Nov meeting

   Adrian: Maciej forwarded a related email to the list on Oct 11

   <adrianba>
   [19]http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/00
   73.html

     [19] 
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0073.html

   <dsr>  scribe: dsr

   Art leaves for meeting with Protocols and Formats WG

   We review the list of specs to see which ones people are interested
   in discussing.

   The topics with the most interest are: CORS (1), Programmable Cache
   (2), Selectors API (2), We Sockets (4), Web Storage (1), Web
   Workers(3), XBL (2).

Web Sockets

   Main question is to update the API spec in line with the progress of
   work on the protocol spec.

   [ we plan to discuss web sockets until the morning coffee break]

   There is now a method to support a clean shutdown of the connection
   and we could consider a way to indicate at the API level whether the
   connection closed cleanly or not.

   Another question is whether to support different data types other
   than UTF-8 strings

   The emerging standard for small amounts of data is array buffer.

   Hixie has added something related to connection shutdown.

   The protocol is being developed in the IETF. If you are interested
   in implementing web sockets, recommend that you get involved with
   the IETF group.

   Protocol issues fall into 2 categories: handshake and message
   framing.

   Framing - support for fragmentation and different kinds of
   encodings.

   Handshake - key design issue is to ensure for security purposes that
   you can't attack/exploit HTTP servers.

   Lots of email traffic, but plenty still to be resolved.

   Implementations?

   Microsoft demoed an implementation at last IETF meeting

   Hoping big protocol questions will be resolved in next few months.

    IETF HyBi WG: [20]http://trac.tools.ietf.org/bof/trac/wiki/HyBi ]

     [20] http://trac.tools.ietf.org/bof/trac/wiki/HyBi

   PLH asks about status of Selectors API

   Some questions relating to test suite

   <plh>  Anne: pb is with default for stringified for undefined and
   null

   Question on support for binary data for web sockets.

   This is under consideration, possibly as array buffer or blob format

   Anne: there may be support for specific streaming formats.

   Any reason why people don't want to use RTSP?

   Certainly, RTSP is a reasonable option. Streaming over HTTP is also
   quite active.

   Firewalls can tilt the balance in favor of HTTP.

   What about SIP?

   No one has hooked SIP to the browser as yet. But one issue is the
   size of the specs for SIP.

   <timeless_mbp>  [STUN:
   [21]http://en.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
   ]

     [21] http://en.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT

   Any interest in using web sockets peer to peer? This would involve
   some API/protocol support for setting up the connection.

   Yes, hixie has specified some steps, but Anne notes that the
   protocol part is left blank.

   This could involve IETF standards e.g. STUN and TURN.

   The discovery process could involve a web server where users
   register for a session.

   <timeless_mbp>  [ WebSockets over UDP
   [22]http://www.mail-archive.com/wha...@lists.whatwg.org/msg21749.htm
   l ]

     [22] http://www.mail-archive.com/wha...@lists.whatwg.org/msg21749.html

   UDP is of interest for gaming

   <timeless_mbp>  [ SCTP:
   [23]http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protoco
   l ]

     [23] http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

   SCTP might be worth looking at.

   But runs into problems with firewalling

   <shepazu>  there is no WebApps WG meeting today, right?

   WonSuk: what is the relationship between websockets and CORS?

   Anne: they are unrelated, but you could say they are connected via
   the same origin check

   Any open source web sockets implementations as yet?

   Python, Java and a few others.

   <timeless_mbp>   some impls: [24]http://websox.org/ ]

     [24] http://websox.org/

   DSR thinking about live editing via websockets.

   Anne: definite advantage for anything realtime.

   <adam>  java impl - [25]http://www.eclipse.org/jetty/ Jetty provides
   an Web server and
   [26]http://java.sun.com/javaee/5/docs/api/javax/servlet/package-summ
   ary.html container, plus support for Web Sockets,

     [25] http://www.eclipse.org/jetty/
     [26] 
http://java.sun.com/javaee/5/docs/api/javax/servlet/package-summary.html

   Doug wanders in ...

   Doug: any interest in talking about touch and table related APIs?

   Yes, but let's wait for Art to come back after coffee

   we break for coffee

   <timeless_mbp>  Break For Coffee

   <ArtB>  ACTION: barstow P&C spec: make it clear in the Abtract or
   Intro that P&C widgets != UI controls [recorded in
   [27]http://www.w3.org/2010/11/01-webapps-minutes.html#action01]

   <trackbot>  Created ACTION-593 - P&C spec: make it clear in the
   Abtract or Intro that P&C widgets != UI controls [on Arthur Barstow
   - due 2010-11-08].

   <ArtB>  ACTION: caceres notify P&F WG when the P&C Conformance
   Checker is published [recorded in
   [28]http://www.w3.org/2010/11/01-webapps-minutes.html#action02]

   <trackbot>  Created ACTION-594 - Notify P&F WG when the P&C
   Conformance Checker is published [on Marcos Caceres - due
   2010-11-08].

   n.b.
   [29]http://yz.mit.edu/wp/web-sockets-tutorial-with-simple-python-ser
   ver/

     [29] http://yz.mit.edu/wp/web-sockets-tutorial-with-simple-python-server/

   we resume after the coffee break

   <timeless_mbp>  Scribe: timeless_mbp

Introductions

   Laslo G - Nokia

   Yael A - Nokia

   Olli P - Mozilla

   Ta - Sony

   Henri Sivonen - Mozilla

   Bryan Sullivan, AT&T

   Zhang Chengyan - China Unicom

   <zhang-chinaunicom>  zhang chengyan from chinaunicom

   <wuj>  wujing from chinaunicom

   <junliao>  I am here

   Jun Liao - China Unicom

   <Johnson>  johnson from Nokia

   Elena R - Institute Telecom Paris

   WonSuk Lee - ETRI Korea

   <adrianba>  Adrian Bateman from Microsoft

   <eliot>  Eliot Graff from Microsoft

   Josh Soref - Nokia

   <wonsuk>  s/Ronsong Lee/Wonsuk Lee/

   <anne>  Anne van Kesteren - Opera

   Mike Smith - W3C

   <adam>  Adam Boyet from Boeing

   <weinig>  Sam Weinig - Apple

   Doug S - W3C

   <dsr>  Dave Raggett, W3C

   <mjs>  Maciej Stachowiak - Apple

   <BoChen>  Bo Chen for ChinaUnicom

   SJ Lee - LG Electronics

   <anne>  (who is the third from Apple who just got in?)

   <weinig>  anne: Geoffrey Garen

   <anne>  aaah

   Han Chu Li - LG Electronics

   <anne>  never met

   Yung Yu Chan - LG Electronics (observer)

   Hiro I - Toshiba

   Tai S - Jig.jp

   <scribe>  Scribe: dsr

   <scribe>  ScribeNick: dsr

   <timeless_mbp>  Geoffrey Garen - Apple

Web Workers

   Art: Hixie's HTML5 workload is slowing down progress on the web
   workers spec

   Ian want's to move the spec to last call status

   Art: we need to process all the last call comments and if anyone
   wants to volunteer to help with that, feel free to come forward.

   Where can we find the bug list?

   <Barstow>  ACTION: barstow Web Workers: add link to bug database to
   the PubStatus page [recorded in
   [30]http://www.w3.org/2010/11/01-webapps-minutes.html#action03]

   <trackbot>  Created ACTION-595 - Web Workers: add link to bug
   database to the PubStatus page [on Arthur Barstow - due 2010-11-08].

   Anne: don't know of any outstanding issues

   if there have been multiple implementations and few comments, that's
   usually a good sign.

   We think Firefox and Opera have implementations.

   Anne: we are working on getting out a test suite

   Do we need an implementation report to get to Last Call.

   No that's needed to exit CR

   Art repeats his request for volunteers.

   Do we have any thoughts on good candidates for the work?

   Doug asks if any of the actual implementors are in the room? [No]

   companies yes

   <Barstow>  ACTION: barstow Web Workers: work with Team to find
   resource(s) to review LC comments and plan for Candidate [recorded
   in [31]http://www.w3.org/2010/11/01-webapps-minutes.html#action04]

   <trackbot>  Created ACTION-596 - Web Workers: work with Team to find
   resource(s) to review LC comments and plan for Candidate [on Arthur
   Barstow - due 2010-11-08].

   We agree on value of shared test suite, but once a spec reaches a
   certain level of stability, energy dries up

   <timeless_mbp>  … and resources get reallocated

   Mike: are there any big applications of web workers out there?

   Doug: want to avoid diverging implementations due to lack of shared
   test suite.

   Implementors keen to see feedback from application developers

   <smaug_>  hmm, there is no https for www.w3.org/Bugs :/

   Maciej: I am interested to see progress on web messaging

   <timeless_mbp>  smaug_: file a bug ;-)

   Anne: I will follow up on the test suites work within Opera.

   [32]http://www.w3.org/2008/webapps/wiki/PubStatus

     [32] http://www.w3.org/2008/webapps/wiki/PubStatus

   for list of specs which are pending availability of time from editor

   <Barstow>  ACTION: barstow PubStatus update Plans for
   Workers/Storage/Event-source that HTML5 Editor workload is the block
   and ask for volunteers [recorded in
   [33]http://www.w3.org/2010/11/01-webapps-minutes.html#action05]

   <trackbot>  Created ACTION-597 - PubStatus update Plans for
   Workers/Storage/Event-source that HTML5 Editor workload is the block
   and ask for volunteers [on Arthur Barstow - due 2010-11-08].

   Art: do we definitely want web messaging split out of HTML5?

   Maciej: publishing web messaging as a first WD is the next step.

   <Barstow>  ACTION: barstow start a CfC to publish a FPWD of Web
   Messaging [recorded in
   [34]http://www.w3.org/2010/11/01-webapps-minutes.html#action06]

   <trackbot>  Created ACTION-598 - Start a CfC to publish a FPWD of Web
   Messaging [on Arthur Barstow - due 2010-11-08].

   Anne: could we make the first WD a Last Call?

   No, but preference is to first do regular WD for 4 weeks before
   moving to Last Call

   Adrian will find someone from Microsoft to help with this, and may
   be even to contribute some tests.

Programmable Cache

   see [35]http://dev.w3.org/2006/webapi/DataCache/

     [35] http://dev.w3.org/2006/webapi/DataCache/

   <timeless_mbp>  [ data cache:
   [36]http://www.w3.org/TR/2009/WD-DataCache-20091029/ ]

     [36] http://www.w3.org/TR/2009/WD-DataCache-20091029/

   <Barstow>  ACTION: barstow ask Nikunj to report the status and plans
   of Programmable Cache to public-webapps [recorded in
   [37]http://www.w3.org/2010/11/01-webapps-minutes.html#action07]

   <trackbot>  Created ACTION-599 - Ask Nikunj to report the status and
   plans of Programmable Cache to public-webapps [on Arthur Barstow -
   due 2010-11-08].

   What is the timeline for this work item?

   The current editor has changed companies, so we are looking for a
   new editor.

   <Barstow>  ACTION: barstow ask Oracle about their level of interest
   in Programmable Cache [recorded in
   [38]http://www.w3.org/2010/11/01-webapps-minutes.html#action08]

   <trackbot>  Created ACTION-600 - Ask Oracle about their level of
   interest in Programmable Cache [on Arthur Barstow - due 2010-11-08].

   Wonsuk: I am interested in helping with this.

   Adrian: looking for better alignment between the specs for
   programmable cache and html5 application cache.

   <MikeSmith>  thread from July 2009:

   <MikeSmith>
   [39]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/th
   read.html#msg260

     [39] 
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/thread.html#msg260

   Anne: spec last updated Jan 2010

   Doug: do we need to do a use case and requirements analysis, and to
   look at extending the application cache, is it sufficiently
   flexible?

   Art: at this point better to work on this in separate spec rather
   than merging them.

   Maciej: app cache comes from work in Google Gears, original use
   cases still exist.

   Adrian: moving this forward depends on people's interest in driving
   it

   Perhaps we need to ask for feedback on limitations of the app cache?

   <MikeSmith>  Mark Nottingham message about problems with the
   programmable cache api -
   [40]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/02
   78.html

     [40] 
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0278.html

   Doug: would be useful to have an organizational memory for all this

   Adrian: we would still need to find someone to work on use cases and
   requirements - could be a consumer not a vendor

   <Barstow>  ACTION: barstow ask public-webapps about creating Use
   Cases and requirements of Program App Caches versus HTML5 App Cache
   [recorded in
   [41]http://www.w3.org/2010/11/01-webapps-minutes.html#action09]

   <trackbot>  Created ACTION-601 - Ask public-webapps about creating
   Use Cases and requirements of Program App Caches versus HTML5 App
   Cache [on Arthur Barstow - due 2010-11-08].

   Facebook as a candidate?

   <timeless_mbp>  MikeSmith: julian reschke from IETF HTTP.next

   <timeless_mbp>  MikeSmith: Mark Nottingham

   <shepazu>  ACTION: Barstow to contact julian reschke and Mark
   Nottingham about Data Cache [recorded in
   [42]http://www.w3.org/2010/11/01-webapps-minutes.html#action10]

   <trackbot>  Created ACTION-602 - Contact julian reschke and Mark
   Nottingham about Data Cache [on Arthur Barstow - due 2010-11-08].

Selectors API

   Discussion on WebIDL default as key to progressing Selectors spec

   Maciej: some implementations may need to change

   Adrian: would that block PR?

   we want to straighten this out in short order.

   Maciej: keen to sort out Level 2 of the Selectors API

   Anne discusses some of the details of what may be dropped

   <mjs>  hi Lachy!

   <Lachy>  hi

   <anne>  Lachy, when are you making the edits you were planning on
   making?

   <mjs>  we were just talking about Selectors API a bit

   <mjs>  was wondering when Level 2 will settle down

   <Lachy>  I don't know when I'll be doing it, cause it depends on when
   I get allocated to a relevant task, but at this stage, I think I'm
   going to drop the queryScopedSelector methods, as they're a bit of a
   mess.

   <Lachy>  the rest of it should be relatively stable.

   <Lachy>  so :scope will stay, matchesSelector will stay.

   Art: let's take the rest of the selector's discussion to the list.
   next topic XBL2

XBL2

   Some discussion has occurred on possibility of mapping XBL2 from XML
   to JSON.

   Could be some syntactic sugar on top of DOM APIs to make some of the
   use cases simpler, but we are blocked on lack of implementations for
   XBL2

   Anne: manifest attribute in place of processing instructions

   <MikeSmith>  [43]related message from Tab in September

     [43] 
http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0912.html

   Lots of experience in using JavaScript for binding, and desire for
   common solution, but there are complications

   XBL2 is awaiting implementation feedback.

   Hixie did provide a revised spec, but there isn't agreement on the
   changes.

   <inserted>  Aharon: Think it makes sense to have javascript allow us
   to determine natively

   <Barstow>  Olli: I don't agree with the recent changes Hixie made to
   XBL

   <Barstow>  ... think it limits the scope too much

   We plan to resume at 1:30

   <IceGuest_77>  quit

   we drift back from lunch

   Art restarts the meeting

   <anne>  pointer to agenda for tomorrow?

   Art ran in to the TAG folks in the corridor and some of them are
   able to drop in if we need them.

   <anne>  [44]http://www.w3.org/2008/webapps/wiki/TPAC2010

     [44] http://www.w3.org/2008/webapps/wiki/TPAC2010

   Doug: some I18N people would like to talk to us about a few topics
   tomorrow, and I would like to discuss those topics briefly today.

   Anne: I want to talk about modularization of DOM3 events.

   Art: let's take that tomorrow.

   Use of XHR in widgets and specific meaning of origin.

   Art: we should defer CORS and web storage until the TAG folks are
   ready.

   <Barstow>  here is DAP's Pub status page:
   [45]http://www.w3.org/2009/dap/

     [45] http://www.w3.org/2009/dap/

Clipboard

   Chaals worked in Clipboard initially, followed by Hixie.

   Anne: my colleague (Hallvord?) has been studying behavior across
   browsers.

   <anne>  "Hallvord R. M. Steen"<hallv...@opera.com>

   Anne: we can safely say that Chaals has stopped working on the
   Clipboard spec.

   Doug: I was an editor and stopped working on it when I saw Hixie
   picking it up in HTML5.

   Anne: we may have an editor for copy and paste. Hixie has said this
   won't be part of the HTML5 spec,

   <shepazu>  Hallvord Steen

   <Barstow>  AB: "Editor is not working on this spec. We may have an
   Editor for the copy-and-paste part."

   (for the pub status table)

   Doug: I volunteer to update the draft to point to relevant work
   elsewhere (this draft is obsolete, please refer to ...)

   <Barstow>  AB: Doug, et. al
   [46]http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications

     [46] http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications

   Art projects the pub status page
   [47]http://www.w3.org/2008/webapps/wiki/PubStatus

     [47] http://www.w3.org/2008/webapps/wiki/PubStatus

   Art updates the pub status for Clipboard as above,

   <Barstow>  ACTION: Doug update Editor's Draft of Window spec to say
   the spec is no longer active [recorded in
   [48]http://www.w3.org/2010/11/01-webapps-minutes.html#action11]

   <trackbot>  Sorry, amibiguous username (more than one match) - Doug

   <trackbot>  Try using a different identifier, such as family name or
   username (eg. dstamper, schepers)

   <Barstow>  ACTION: schepers update Editor's Draft of Window and REX
   specs to say the specs are no longer active [recorded in
   [49]http://www.w3.org/2010/11/01-webapps-minutes.html#action12]

   <trackbot>  Created ACTION-603 - Update Editor's Draft of Window and
   REX specs to say the specs are no longer active [on Doug Schepers -
   due 2010-11-08].

   Anne: move element traversal into DOM4 ...

   Art: are there any process issues for that

   Some discussuion whether we will discuss UMP

   Art: if we do discuss UMP, we should ensure the TAG is represented
   ... server-sent events, anyone interested in discussing that?

   Currently blocked on HTML5 workload

   <anne>  [50]http://www.w3.org/2008/webapps/charter/#decisions

     [50] http://www.w3.org/2008/webapps/charter/#decisions

   <Barstow>  ACTION: barstow work with WebApps Team and Anne to find a
   way for W3C to host Opera's event-source tests [recorded in
   [51]http://www.w3.org/2010/11/01-webapps-minutes.html#action13]

   <trackbot>  Created ACTION-604 - Work with WebApps Team and Anne to
   find a way for W3C to host Opera's event-source tests [on Arthur
   Barstow - due 2010-11-08].

   Anne: I published a test suite, but to publish it on W3C site we
   need some decision on hosting PHP scripts

   <anne>  [52]http://tc.labs.opera.com/apis/XMLHttpRequest/ and
   [53]http://tc.labs.opera.com/apis/EventSource/

     [52] http://tc.labs.opera.com/apis/XMLHttpRequest/
     [53] http://tc.labs.opera.com/apis/EventSource/

   Dom: depending on the kind of PHP script there should be a way to
   host it on a W3C server.

   <anne>  [54]http://tc.labs.opera.com/svn

     [54] http://tc.labs.opera.com/svn

   Anne: all the code is available if you have subversion

   <Barstow>  ACTION: barstow add Opera's test suite for EventSource to
   the PubStatus page (see mins from 1-Nov-2010 for the link) [recorded
   in [55]http://www.w3.org/2010/11/01-webapps-minutes.html#action14]

   <trackbot>  Created ACTION-605 - Add Opera's test suite for
   EventSource to the PubStatus page (see mins from 1-Nov-2010 for the
   link) [on Arthur Barstow - due 2010-11-08].

   Chaals walks in and is introduced by Doug :)

   <anne>  dom, one is somewhat evil, writing and reading files

   <dom>  brrr

   <dom>  any chance you could document a bit more what they do and what
   they require?

   <anne>  there's no localStorage in PHP

   The TAG will join us at 4pm.

   <anne>  dom, basically access to everything from the request and
   being able to do pretty much anything in the response

   <anne>  dom, and some kind of state thing on the server

WebSQL

   <dom>  right; I was thinking of actually comments in the PHP code :)

   <anne>  dom, come on, it's only a couple of lines

   Same situation as a year or more,

   two implementations but no will to move it forward

   <dom>  they are, anne, but these things will have to be maintained
   for X years; I'm thinking to the poor soul that will have to port
   these things to PHP 12 (or Scala 5)

   Chaals: we can republish it as a NOTE

   Anne: we still think it's interesting and don't want to remove it.

   Doug: we can change to a Note and when interest renews, we can bring
   it back

   Art displays the current spec which notes in red that we only have
   implementations on top of SQLite and don't have a separate spec for
   the subset of SQL involved.

   DSR: is it a strict subset of SQL standard?

   No, it also includes some extensions

   Dom: the only drawback of switching to Note is that you would have
   to restart the IPR process to bring it back to Rec-track

   We agree to republish as a WG Note

   <Barstow>  ACTION: barstow start a CfC to publish Web SQL Database as
   a Working Group Note (and hence signal the spec is no longer on the
   REC track) [recorded in
   [56]http://www.w3.org/2010/11/01-webapps-minutes.html#action15]

   <trackbot>  Created ACTION-606 - Start a CfC to publish Web SQL
   Database as a Working Group Note (and hence signal the spec is no
   longer on the REC track) [on Arthur Barstow - due 2010-11-08].

XHR + Widgets

   <anne>
   [57]http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/03
   91.html

     [57] 
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0391.html

   Brian posted email on this ...

   Brian explains complications relating to cross domain security
   model.

   Brian widgets have no defined origin

   DSR asks why widgets don't have an origin

   Explanations relating to not wanting to leak information,

   installed apps need to satisfy a higher bar for security.

   Signed widgets could imply an origin, but how would this be used in
   a protocol like redirect

   <noah>  NM: As a tracking mechanism, I could typically track two
   actions: one long term for the complete result, linking to the
   detailed goals; the other short term for the next draft

   <noah>  LMM: My focus is more on the quality of the result than on
   the date

   <noah>  LMM: We should have output regularly

   <noah>  AM: Difficulty in getting reviewing

   Brian: if I issue a request vis XHR and it pings around several
   redirects, do I as an app author need to do anything to be involved
   in the redirects
   ... user agent is supposed to retain security token from redirect
   response.

   timeless: Similar story applies to plugins with events for each
   redirect

   <timeless_mbp>
   [58]https://mail.mozilla.org/pipermail/plugin-futures/2010-October/0
   00168.html

     [58] 
https://mail.mozilla.org/pipermail/plugin-futures/2010-October/000168.html

   <timeless_mbp>
   [59]https://wiki.mozilla.org/NPAPI:HTTPRedirectHandling

     [59] https://wiki.mozilla.org/NPAPI:HTTPRedirectHandling

   Anne: are you saying redirects don't work with OAUTH today?

   Brian: you lose information and your app would have to be OAUTH
   aware

   <timeless_mbp>
   [60]http://developer.linkedin.com/message/1032;jsessionid=704AF1CC29
   2EA4F8582CB7C91B21F7C7.node0#1032

     [60] 
http://developer.linkedin.com/message/1032;jsessionid=704AF1CC292EA4F8582CB7C91B21F7C7.node0#1032

   Anne: aren't redirects supposed to be transparent

   <timeless_mbp>  1. Oct 26, 2009 12:28 PM in response to: caleb

   <timeless_mbp>  Re: OAuth Redirect not happening?

   <timeless_mbp>  Did you add your oauth_callback parameter to the
   requestToken request or the authorize request?

   <timeless_mbp>  If the latter then we default to an out-of-band
   callback.

   <timeless_mbp>  You may need to insure that your oauth library is
   using 1.0a.

   Brian: twitter and others are including info in redirect responses.

   <timeless_mbp>  OAuth [61]http://tools.ietf.org/html/rfc5849]

     [61] http://tools.ietf.org/html/rfc5849

   Anne: it is kind of weird that widgets want to follow web model but
   not in full

   We should notn't conflate [i18n api in javascript core - as opposed
   to dom] use of redirects with widgets spec as it applies more
   generally

   Right now our security model is origin based.

   origin doesn't have to be an HTTP URI

   Anne: CORS does have a wildcard for URI
   ... widget could send an arbitrary token for origin

   <dom>  (so maybe there needs to be a work item on Widgets Origin?)

   Henri: broken browsers can fake orgin as can broken widgets, the
   attack you are trying to prevent is a rogue widget running on a
   trusted platform accessing private data
   ... user would be recognized by normal login process. The widget
   would be identified by a hash of the widget so that the server has
   reasonable belief that the widget hasn't been tampered with,
   assuming a trusted widget runtime.
   ... the hash is computed in widget package file.

   Server needs to remember the hash for the widgets they issued/trust

   The hash is a proxy for the identify of the widget

   Anne: widgets are siloed from the browser

   Brian: their is no guarantee that the browser couldn't execute the
   widget

   Anne: it would still be sandboxed

   Henri summarises the trust model whereby server uses checksum over
   widget's code as a check on its code as its identity.

Web Events

   Art: last week W3C Director approved new WG on events. Doug will
   review its scope to use us now.

   <Barstow>  Web Events home: [62]http://www.w3.org/2010/webevents/

     [62] http://www.w3.org/2010/webevents/

   <Barstow>  Web Events: Charter

   Two main aims: touch interfaces (including pen tablets, white boards
   etc) we call these low level or physical events

   <Barstow>  ... [63]http://www.w3.org/2010/webevents/charter/

     [63] http://www.w3.org/2010/webevents/charter/

   Other events are intentional e.g. "undo" and at a higher level than
   say "click".

   Doug calls these user level events.

   We won't be covering gestures which vary between devices.

   We will provide a non-normative document describing gestures for
   informative purposes.

   Doug invites interested people to join the new WG

   See [64]http://www.w3.org/2010/webevents/

     [64] http://www.w3.org/2010/webevents/

   Art: we want to develop a shared terminology and a set of use cases.

   The subsequent requirements analysis will help us to filter aspects
   that are in scope from those that are out of scope.

   Doug: hopes to come up with something that is universally
   acceptable.

   Chaals: we are already signed up to the new WG and believe that
   higher level events are really important

   This will simplify web app development in the long run

   Doug: also good for implentors

   Sam: can't talk about touch, but there has been some work on higher
   level events (e.g. relating to ARIA)

   There are challenges to do with privacy, e.g. disclosing that you
   are using a screen reader.

   Doug: we are open to suggestions

   Olka: there is some commonality in higher level events across
   platforms (conceptually)

   Doug: if we can find a sweet spot for a useful set of gestures that
   are universal and vendors are agreeable we can move forward.
   ... we are not going to specify the specific user actions involved
   in gestures e.g. pinch.

   Brian: if there is a common set of events regardless of how they are
   triggered, then that is still in scope, right?

   Chaals summarises...

   cites "back" action as example

   <Barstow>  s/Olka:/Ilkka:/

   Allowing app developers to bind their code to these higher level UI
   events makes their code easier to develop and more robust.

   Soref: other examples include pan and zoom.

   Chaals: this topic has been around for a decade e.g. hover, click
   and activate

   we should leave this to the new Web Events WG!

CORS and UMP

   Is anyone going to implement UMP? Answer no.

   Art: who is going to push CORS into Last Call?

   Any major issues to resolve for that to happen?

   <dom>  [65]http://www.w3.org/2008/webapps/track/products/7 has one
   raised issue about confused deputy

     [65] http://www.w3.org/2008/webapps/track/products/7

   Doug: UMP has been actively edited, but just not implemented.

   Art: easiest way to kill UMP is to move CORS forward,

   Dom: dependencies don't effect moving spec to Last Call.

   Anne: some issues to resolve (e.g. 3 person handshake)

   <Barstow>  ACTION: barstow work with Anne on a plan to move CORS to
   LCWD [recorded in
   [66]http://www.w3.org/2010/11/01-webapps-minutes.html#action16]

   <trackbot>  Created ACTION-607 - Work with Anne on a plan to move
   CORS to LCWD [on Arthur Barstow - due 2010-11-08].

   we break for caffeine

   <anne>  s/3 person/3 party/

   we resume after the coffee break

   The data cache spec was defined to address a number of features such
   as providing access to email attachments when you are offline

   <dom>  [67]DataCache API Editors draft

     [67] http://dev.w3.org/2006/webapi/DataCache/

   (says Eric)

   The TAG members introduce themselves.

   The TAG expressed an interest in hearing about Web Storage, a spec
   edited by Hixie, who unfortunately isn't present today.

   <dom>  [68]Architecture of the World Wide Web, Volume One (15 Dec
   2004)

     [68] http://www.w3.org/TR/webarch/

   Noah explains that TAG members are mainly hear to listen, and
   describes the context.

   Maciej: we do have people hear with some expertise in this topic who
   could offer their comments.

   Local storage mechanisms can boost performance of online web apps,
   and enable them to work when a connection drops out.

   This comes with privacy implications and many of you will have heard
   of evercookie which works very hard to preserve cookies against
   deletion.

   HTTP cookies are just one of many ways for sites to track users, and
   browsers doesn't have full control over all of them.

   Browsers are evolving to support users wishing to clear all
   information relating to a given site.

   This should help with privacy.

   There are certain ways to track users without any local storage,
   e.g. finger prints based upon the browser's configuration (e.g. what
   fonts are locally installed).

   <timeless>   [69]http://www.unc.edu/courses/jomc050/idog.jpg ]

     [69] http://www.unc.edu/courses/jomc050/idog.jpg

   Noah: when you use the web in general, what assurances can we offer?

   <dom>  (to me, this seems to point to the fact that browsers should
   behave separately when you're logged in and when you're not)

   Maciej: using the browser in a safe mode and accessing sites through
   torr (anonymising proxy) is about as good as is possible.

   however, this will provide a reduced user experience ...

   And even then there may be ways to perform linkability analyses.

   <timeless>  [Exploring the Use of Discrete Gestures for
   Authentication [70]http://eprints.comp.lancs.ac.uk/2204/]

     [70] http://eprints.comp.lancs.ac.uk/2204/

   <dom>  ["on the internet, nobody knows you're a dog" — but nowadays,
   on the internet, everybody knows your dog's name]

   Dan: do local URIs offer any help?

   <timeless>  [ And here's a "Reality" Check
   [71]http://www.unc.edu/courses/jomc050/sum97/dog2.gif — from
   [72]http://www.unc.edu/depts/jomc/academics/dri/idog.html ]

     [71] http://www.unc.edu/courses/jomc050/sum97/dog2.gif
     [72] http://www.unc.edu/depts/jomc/academics/dri/idog.html

   [ we agree to discuss storage not privacy to avoid going off into
   the weeds ]

   Maciej: HTML5 has some new APIs e.g. for back function that can be
   helpful.

   <dom>  [73]HTML5 pushState() method to help manage URI-based views

     [73] http://dev.w3.org/html5/spec/history.html#dom-history-pushstate

   Chaals: we may want to ask what's different about URIs in the
   context of web widgets.

   Right now widgets don't have a URI of their own, so that they don't
   have a URI to hang their data off.

   We may want a way to distinguish between a local copy and the
   version on the server, but that is a lesser issue.

   Ashok: widgets don't have URIs, right, so how are they identified?

   Chaals: the current widget spec doesn't provide for exposing a URI.

   Larry: URI is not just a resource identifier, it is also a means for
   communicating, e.g. sharing a bookmark with someone

   You don't want to encapsulate all of the application state in the
   URI, but rather to provide a means for reconstituring the important
   state, e.g. the same route on a map, even in the map is in a
   different language.

   <timeless>  (of note, the sharable bits that Google Maps exposes via
   "share" encode the Language, which generally annoys me)

   Anne: as Maciej mentioned HTML5 introduces a means for an
   application to push the current state and to encapsulate this in a
   URL for sharing with others, e.g. via copy and paste

   This avoids the need for the fragment identifier for the state

   The application may store state locally or in the server.

   Larry: it would be nice if the way you name things is independent of
   whether they are in local storage or on the server

   If apps have too much state then you should try to put it into a
   URI.

   Chaals and Larry agree on the need for providing advice to
   developers on good practices.

   Doug: we can't know everything that people want to do, and can only
   do our best

   Anne: trying to write guidelines for developers is tough

   Noah: generally agree with what has been said

   I am not ready to say you need a URI for every item in a SQL store,
   but it is worth asking the question to understand the issues.

   The TAG's role is to point out that there is an issue somewhere in
   here when it comes to storage.

   <dom>  (I'm not sure client-side storage is significantly different
   from server-side storage; many server-side applications don't use
   well URIs to expose state either)

   If people end up putting a lot of data in local storage that isn't
   addressable then this is a problem.

   <Kai>  (except availability might be an issue)

   i.e. pulling things out of web space...

   Chaals draws analogy with pulling alligators out of the swap before
   the architects build the city...

   Ashok: why don't you guys let the browser address things in
   databases?

   We do have SQlite. Ashok responds, I mean a real datab...@! :)

   Ashok: define a way to provide a SQL interface to requesting data,
   and returning it in whatever format makes sense

   Dan asks about the various forms of local storage under
   consideration.

   Chaals: for various reasons it is unlikely that the SQL interface
   will make it to REC

   All of the major browser vendors have indicated there support for
   IndexDB

   <chaals>  a/All of the //

   Sam: file storage API is yet another mechanism under consideration.
   This is sandboxed from the devices full file system.

   <anne>  [74]http://dev.w3.org/2009/dap/file-system/

     [74] http://dev.w3.org/2009/dap/file-system/

   <anne>  [75]http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
   is it specifically

     [75] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html

   <anne>  (for some confusing reason in the DAP directory)

   <anne>  (well, historical)

   <dom>  (because DAP rocks)

   Larry: I have an update of the file: scheme for URIs and would love
   to see that involved.

   This hides OS dependent path syntax issues.

   Art: any more questions on both sides?

   Dan: sounds to me that the TAG could work on some kind of developer
   guidelines document if that is out of scope for Web Apps WG

   Chaals: that is out of scope for us, so yes that would be something
   for you to think about

   Larry: to clarify I am not editing the file: URI scheme spec and
   would appreciate someone else taking it on.

   [ the TAG representatives leave the room ]

   <chaals>  scribe: chaals

i18n

   <Barstow>  ScribeNick: ArtB

DOM 3 Events Input Locale

   <chaals>  ScribeNick: chaals

   Aron: (I work for Google.)

   <timeless>  s/Aron/Aharon/

   Aron: when working on online editor we realised it would be good to
   know the keyboard locale being used, in th context of smart quotes
   (langauge specific, and common in word-processors)

   <timeless>  s/th context/the context/

   i/Aharon/Richard: I work for W3C on i18n/

   <timeless>  s/langauge/language/

   <anne>  I think it reads Aharon

   s/Aron/Aharon/

   <anne>
   [76]http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0044.html

     [76] http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0044.html

   scribe: Other usecase is inline directional styling. If you are
   typing RTL you often need to quote an LTR language (usually english)

   <timeless>  s/english/English/

   scribe: Problem is if the insert starts with punctuation or numbers,
   etc., you get problems unless the indicators are explicit.

   s/indicators/directional indicators/

   scribe: Editors provide a user control to indicate paragraph
   direction, but not for indicating a span within a larger paragraph.
   ... Word is clever and detects the keyboard being used. If I am
   typing in hebrew and switch to english keyboard, it switches the
   direction.

   <timeless>  s/hebrew/Hebrew/

   <timeless>  s/english/English/

   scribe: Generalising this, using an IME, voice recognition, etc, you
   still want to know what language it is set up for.

   <timeless>  s/direction/direction for the block of text entered in
   that language/

   scribe: Many of these devices are langauge specific.

   <timeless>  s/langauge/language/

   scribe: The basic idea is to provide a keyboard-locale property as
   BCP47 language code for key and text events.
   ... Doesn't mean that what was typed is in that locale, but it gives
   a good-enough heuristic to give a significant improvement.
   ... Besides that, having a global object that has an input-locale
   property would be useful.
   ... And an event that would indicate that locale has changed.

   <timeless>  s/locale/the locale/

   scribe: (For other use cases than those identified).
   ... Complication: You could use multiple input devices each
   configured to a different language.
   ... Didn't deal with that, but worth thinking about.

   DougS: We talked about a number of mechanisms in DOM 3. Suggested
   that having it in the event might become heavy.
   ... You can point to a static variable...
   ... Another proposal was having the global property, and we rejected
   it for 2 reasons: Complication identified, and it is yet another way
   to profile/sniff users, and we want to avoid this
   ... I would feel happy typing stuff into a page - I have already
   given that some trust, so I am OK with it doing some more detection.
   ... I don't want a spam popup to get my language information
   though...

   ??: What if you synthesise an event through the DOM?

   Josh: Have to be doing input...

   DougS: Keyboard inputs and text

   Sam: Usually you have to fill in the properties yourself, or they
   don't show up.

   <Barstow>  s/??:/Geoffrey/

   Sam: If a popup captures key inputs (clickjacking...) then you still
   have an issue

   Anne: Valid concern. If you modify it you cannot modify init
   methods.

   Maciej: Init Methods --

   <anne>  nuke it

   Josh: Next events thing could deal with that.

   Geoffrey: If we don't change the init, then you don't have a privacy
   problem.

   Anne: Sounds complicated - you eed to have a locale dictionary.
   Would it be possible to get the right behaviour in the User Agent
   instead?

   Aharon: I don't know all the use cases - I've given you the ones
   that came up immediately on a project.

   DougS: We got basically the same feedback from MS Live.

   Aharon: It's not direction specific, it is also relevant switching
   from russian to english keyboard. French speakers would use french
   quotes, but if they type english they want english quotes but they
   are likely to keep using a french keyboard.

   <timeless>  s/russian/Russian/

   <timeless>  s/english/English/

   <timeless>  s/english/English/

   DougS: Would fail there, but it is still sufficiently useful

   Aharon: Yes. Talking about heuristics, yes they are complex. But the
   people who want to support this are willing to deal with the
   complexity, but they don't have the underlying information to
   support doing so.
   ... having the APIs available in javascript would be very useful.
   But I don't think this is the right forum for that (there are
   Javascript APIs being proposed for i18n purposes).
   ... The capability is included in javascript packages out there
   (e.g. in Google closure you can get a good guess about whether a
   language code implies RTL or LTR)

   <timeless>  [ Google Closure
   [77]http://code.google.com/closure/library/ ]

     [77] http://code.google.com/closure/library/

   Anne: This or HTML-WG could be the right forum for talking about
   APIs...

   DougS: But not this spec.

   Aharon: Think there is an effort to include native i18n
   functionality in javascript.

   <timeless>  s/javascript/ecmascript/

   Anne: Don't think it makes sense for that to cover this.

   Olli: I think we agree already.

   Anne: Still have concern about fingerprinting

   Geoffrey: Only works if people are typing

   [Yes, but people type all the time]

   CMN: A highly efficient web timing interface is likely to be more
   useful for improved fingerprinting.

   DS: Think the concerns are valid, but this is useful enough to
   override them. Should be a note in the spec explaining the issue

   Anne: Users are not going to read the spec, and this is relevant to
   users. But I am not opposed.

   MJS: Useful to note so people who want to make anti-fingerprinting
   see it.

   Olli: Web apps still need to handle the case where input-locale is
   not avialable.

   <timeless>  s/avialable/available/

   Aharon: Yes. The spec already notes what to do when this happens.

   DougS: Pasting means there is no input locale.

   Aharon: And think it will stay like that. This is specifically about
   things being input.

   Anne: Why put it on keyboard? Why not just on text - that seems
   sufficient and I don't see the value for keyup/down etc.

   EricU: Having it for keyup/down could be useful to write a really
   powerful editor. E.g. if you want to deal with ctrl-D you have to
   get to the level of key events.

   CMN: Think Anne is right...

   <smaug_>
   [78]http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0024.html

     [78] http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0024.html

   CMN: don't need to handle text and key input if you can just handle
   key input.

   s/ if you can just handle key input/, text is enough because command
   keys are not locale-dependent in effect/

   Josh: But if you write a rich editor you just trap key events,
   rather than having to deal with text input at all.

   DougS: The plan is to add the proposal, and do it...

   Doug claims Adrian thought this was great and has been agitating for
   it for ages.

   <timeless>  this was
   [79]http://www.w3.org/2008/webapps/track/issues/119

     [79] http://www.w3.org/2008/webapps/track/issues/119

   [Adjourned for the day]

Summary of Action Items

   [NEW] ACTION: barstow add Opera's test suite for EventSource to the
   PubStatus page (see mins from 1-Nov-2010 for the link) [recorded in
   [80]http://www.w3.org/2010/11/01-webapps-minutes.html#action14]
   [NEW] ACTION: barstow ask Nikunj to report the status and plans of
   Programmable Cache to public-webapps [recorded in
   [81]http://www.w3.org/2010/11/01-webapps-minutes.html#action07]
   [NEW] ACTION: barstow ask Oracle about their level of interest in
   Programmable Cache [recorded in
   [82]http://www.w3.org/2010/11/01-webapps-minutes.html#action08]
   [NEW] ACTION: barstow ask public-webapps about creating Use Cases
   and requirements of Program App Caches versus HTML5 App Cache
   [recorded in
   [83]http://www.w3.org/2010/11/01-webapps-minutes.html#action09]
   [NEW] ACTION: barstow P&C spec: make it clear in the Abtract or
   Intro that P&C widgets != UI controls [recorded in
   [84]http://www.w3.org/2010/11/01-webapps-minutes.html#action01]
   [NEW] ACTION: barstow PubStatus update Plans for
   Workers/Storage/Event-source that HTML5 Editor workload is the block
   and ask for volunteers [recorded in
   [85]http://www.w3.org/2010/11/01-webapps-minutes.html#action05]
   [NEW] ACTION: barstow start a CfC to publish a FPWD of Web Messaging
   [recorded in
   [86]http://www.w3.org/2010/11/01-webapps-minutes.html#action06]
   [NEW] ACTION: barstow start a CfC to publish Web SQL Database as a
   Working Group Note (and hence signal the spec is no longer on the
   REC track) [recorded in
   [87]http://www.w3.org/2010/11/01-webapps-minutes.html#action15]
   [NEW] ACTION: Barstow to contact julian reschke and Mark Nottingham
   about Data Cache [recorded in
   [88]http://www.w3.org/2010/11/01-webapps-minutes.html#action10]
   [NEW] ACTION: barstow Web Workers: add link to bug database to the
   PubStatus page [recorded in
   [89]http://www.w3.org/2010/11/01-webapps-minutes.html#action03]
   [NEW] ACTION: barstow Web Workers: work with Team to find
   resource(s) to review LC comments and plan for Candidate [recorded
   in [90]http://www.w3.org/2010/11/01-webapps-minutes.html#action04]
   [NEW] ACTION: barstow work with Anne on a plan to move CORS to LCWD
   [recorded in
   [91]http://www.w3.org/2010/11/01-webapps-minutes.html#action16]
   [NEW] ACTION: barstow work with WebApps Team and Anne to find a way
   for W3C to host Opera's event-source tests [recorded in
   [92]http://www.w3.org/2010/11/01-webapps-minutes.html#action13]
   [NEW] ACTION: caceres notify P&F WG when the P&C Conformance Checker
   is published [recorded in
   [93]http://www.w3.org/2010/11/01-webapps-minutes.html#action02]
   [NEW] ACTION: Doug update Editor's Draft of Window spec to say the
   spec is no longer active [recorded in
   [94]http://www.w3.org/2010/11/01-webapps-minutes.html#action11]
   [NEW] ACTION: schepers update Editor's Draft of Window and REX specs
   to say the specs are no longer active [recorded in
   [95]http://www.w3.org/2010/11/01-webapps-minutes.html#action12]

   [End of minutes]



Reply via email to