- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Sat, 27 Apr 2013 09:55:03 -0400
- To: public-webapps <public-webapps@w3.org>
- CC: Daniel Austin <daaustin@paypal-inc.com>
The Draft minutes from WebApps' April 26 f2f meeting are at the
following and copied below:
<http://www.w3.org/2013/04/26-webapps-minutes.html>
If you have corrections, comments, etc., please reply by May 2.
Thanks very much to Josh Soref for once again being an excellent Scribe!
And a Huge thanks to Daniel Austin and PayPal for hosting the meeting!
-AB
W3C <http://www.w3.org/>
- DRAFT -
Web Applications WG F2F Meeting
26 Apr 2013
Agenda <http://www.w3.org/wiki/Webapps/April2013Meeting>
See also:IRC log <http://www.w3.org/2013/04/26-webapps-irc>
Attendees
Present
Art_Barstow, Charles_McCathieNevile, Josh_Soref, Robin_Berjon,
Yves_Lafon, Ted_Oconnor, Laszlo_Gombos, Tyler_Barton,
Adrian_Bateman, Glenn_Adams, Doug_Turner, Bryan_Sullivan, Bin_Hu,
Arnaud_Braud, Yosuke_Funahasi, Jae_Won_Chung, Hiroyuki_Aizu,
adrianba, Lyle_Troxell, eliot_graff, Yosuke_Funahashi, krisk,
Jungkee_Song, Eduardo_Fullea, Jonghong_Jeon, Mike_Smith,
Arun_Ranganathan, Wonsuk_Lee, MikeSmith!, hober
Regrets
Chair
Art, Charles
Scribe
Josh_Soref
Contents
* Topics <http://www.w3.org/2013/04/26-webapps-minutes.html#agenda>
1. testing <http://www.w3.org/2013/04/26-webapps-minutes.html#item01>
2. Move to Github
<http://www.w3.org/2013/04/26-webapps-minutes.html#item02>
3. Progress Events
<http://www.w3.org/2013/04/26-webapps-minutes.html#item03>
4. XHR Status
<http://www.w3.org/2013/04/26-webapps-minutes.html#item04>
5. Coordination (TC39)
<http://www.w3.org/2013/04/26-webapps-minutes.html#item05>
* Summary of Action Items
<http://www.w3.org/2013/04/26-webapps-minutes.html#ActionSummary>
------------------------------------------------------------------------
<ArtB> Scribe: Josh_Soref
<ArtB> ScribeNick: timeless
<Yves> i
<Yves> trackbot, start telcon
<trackbot> Meeting: Web Applications Working Group Teleconference
<trackbot> Date: 26 April 2013
<Ms2ger> Ta
<darobin> Shenzhen
<ArtB>*ACTION:*barstow announce the WG will meet during TPAC 2013 in
November [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action01]
<trackbot> Created ACTION-692 - Announce the WG will meet during TPAC
2013 in November [on Arthur Barstow - due 2013-05-03].
<darobin> ScribeNick: darobin
chaals:that was painless
... the chartering stuff
... what do we need to add or remove
... we have a spec called URL, we asked if people would work on it
<ArtB>Inventory of Charter updates that need to be made or might be made
<http://www.w3.org/wiki/Webapps/Charter>
chaals:Anne is not in WebApps, so can't edit
... no one in WebApps is editing it
... Anne is working on it outside W3C
... should we keep it in our charter
<hallvord_> Hi Jungkee
Robin:if we're just republishing, why not automate it?
chaals:uh, we actually want a responsible editor
<Ms2ger> I note that chaals said "Anne puts his spec in the public
domain, so you can just copy it"
dougt:how about we could just resolve the dispute over the licensing
instead?
chaals:we could, but that's outside the scope of this group
... if the AC get a consensus, then the problem goes away
... until that happens, we need to figure out what to do with that spec
... if no one is committing to it, seems pointless to have it in the charter
robin:just pointing out that this is pretty fundamental
bryan:is this really cut and paste?
group:yeah
bryan:so why not just do it?
chaals:because no one volunteers
dougt:the problem is the license, so we should transition to an open license
ArtB:do we want to start a CfC to drop URL?
chaals:alternative proposal...
robin:the group could go on strike until there's a new license
chaals:I can take over URL if the group appoints me to it
<ArtB>*ACTION:*charles to be the default Editor of URL spec [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action02]
<trackbot> Created ACTION-693 - Be the default Editor of URL spec [on
Charles McCathie Nevile - due 2013-05-03].
chaals:some work is scoped but not listed explicitly, e.g. Streams
<smaug> tobie:http://www.w3.org/wiki/Webapps/April2013Meeting
<ArtB>pending Charter updates <http://www.w3.org/wiki/Webapps/Charter>
chaals:I plan to draft a new charter, and list deliverables more precisely
... expect to see a proposal
<ArtB>*ACTION:*charles prepare a Draft charter update for the WG to
review [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action03]
<trackbot> Created ACTION-694 - Prepare a Draft charter update for the
WG to review [on Charles McCathie Nevile - due 2013-05-03].
chaals:and get the AC to support it
adrianba:are we planning to add application manifest?
chaals:we are planning to keep it
<hallvord_> the strike idea was interesting ;-)
<Ms2ger> And the editors that edit the majority of webapps specs have
already stopped working through W3C
adrianba:I think it's different from a packaging proposal
chaals:if you look through that document, it has all of it, and we're
taking a subset
ArtB:but we can be more explicit
chaals:the DOM can go there as "we'll do something"
<hallvord_> web spec proletariat's unacceptable working conditions?
#firstworldproblems - sort of
chaals:push Push out of the charter
<hallvord_> (to be clear, I think the licencing stuff SHOULD be resolved
and expect it to happen eventually)
chaals:I believe support has increased
... notably Mozilla who weren't interested are now working on it
[scribe notes "for a change"]
bryan:in the geological time scale of webapps, this was brought here
seconds ago
... SysApps may be a place to develop it, but I woudl hesitate to move
something out just because there's controversy
chaals:no
... there has been suggestion to push it out
... there has been a PAG
<ArtB>exclusions for Push API
<http://www.w3.org/2004/01/pp-impl/42538/status#current-disclosures>
chaals:Yandex supports keeping push in
... any other opinion? Bryan wants it in
eduardo:yes, we want it in
dougt:it needs to be in this WG
chaals:I don't see it as value to move the PAG around
arnaud:I also support keeping it in
chaals:the whole point of a PAG is you don't have to stop the work
dougt:I think we need to get a lawyer to go through this, we can provide
prior art
chaals:yes, the PAG does that, we continue on the tech work
[scribe made it to w3cmemeshttp://w3cmemes.tumblr.com/image/48935613505]
chaals:eduardo, do you want to do push api tech stuff now?
eduardo:the goal of this spec is to provide an API for apps to register
for push notifications
... you can see the API to register, the UA sets up a push notification
channel
<ArtB>Push API ED <https://dvcs.w3.org/hg/push/raw-file/default/index.html>
eduardo:the server can then deliver push notifications
... details of the API
... the push manager interface
... exposed on Navigattor
... a method to register
... registration is now simpler, no params
... returns a DOMRequest
... unregister() from specific endpoint
... list registrations
... Push endpoint is a URL where the app server can send notifications
to be delivered to the application
... list of server protocols that can be used to send notifications to
the push server
... discover which are supported
... message interface, represents a system message
... used to inform the application when a notification is received
... this interface has two attributes
... allows app to map to specific push registration
... the version marks the latest version of the content that is available
... the application needs to fetch from the corresponding application sever
... the PushRegisterMessage interface
... represents additional system message
... signals application that the notificaiton is now invalid and it
needs to re-register
... last section
... system messages, describes the names of the system messages and the
interfaces to use for them
... steps that must be followed when a notificaiton is received
... clarifications?
<Zakim> MikeSmith, you wanted to ask about NavigationController and charter
<MikeSmith> chaals, the point I wanted to make is that the scope of
NavigationController is significantly larger than just appcache, so I
don't think we can just assume/declare that NavigationController is in
scope. Because I think it's not, as far as the current charter and the
move-over-from-HTML clause.
eduardo:this is part of FirefoxOS, developed by Mozilla and Telefonica
chaals:it seems clear to me
dougt:I have two or three things about this
... for our phone, we use system messages and manifests and all
... there's internal debate about how we deliver a message to an
application that's not active, the window is gone
... I don't think we have general agreement on that
... system messages or manifest might work
... but I'm not sure that that's the best for the web (some will disagree)
... so we're looking for a solution
... one option is a Function Future, similar to a future
... but the JS engine stores is, and you can ask that to give you back a
function later that you can execute
... but the problem is, when a webapp is no longer running, how do you
deliver a message to it?
... this spec is tighttly coupled to system messages, which may or may
not be the way to do it
... we keep things simple, there's no need to sync data
... we didn't just want to use the notification tray
... we want to build an API that enabled more than that, including sync
services
... the app might do a bunch of things before putting up a notification
(or not)
... it's very simple and basic so that people can build on top of it
... no data, low level signalling service
... the protocol based on something called Thialfi
... has a bunch of pros
... if the push server goes away
... you can bring it back up with no data, and the protocol will self repair
... if you try to do the same, you'll probably come to the same conclusion
<lyle>http://research.google.com/pubs/pub37474.html
sicking:the whole problem to sending messages to something that may not
be running is something we're facing in the Notification API as well
... if the message is clicked and the app has gone away, we don't know
what to do
... I think we can solve this without relying on manifest
[scribe hints that Intents/Activities are a solution avenue here]
bryan:just a few comments
... simplification to deliver only signal, I understand the intent
... that's fine, better than nothing
... we do have more than ten years of experience in delivering actual
payloads to apps
... and we've enabled lots of infrastructure that you enjoy everyday
... so it is safe and we've been doing it for many years
... but I agree that if you signal the app and let it decide, it's secure
... and in fact it is the number one approach we've been using all these
years
... so we're good with that
... comments might be resolved?
... push server design considerations (eg robustness, scalability)
... do we need some content in the spec? we could provide something
... second thing had to do with security considerations
... probably addressed by removing the payload
chaals:yes, design considerations are useful to put in spec so that
people udnersntad what you're doing
sicking:first question was about privacy being solved by not having messages
... it certainly helps a lot
... I don't have a lot of experience as for the server considerations
... the concerns we had about scalability with the previous proposal is
something we attempted to address
... by allowing the server to drop information and autorepair
... I'm not good enough at server development to say that this aspect is
solved
... but we feel a lot more comfortable with this
bryan:eliminating the payload certainly solves a lot of scability and
sync issues
... to issues a request and get something you need, but it's still
unclear what the actual process is
... do we want to include example of how it works out on the wire?
dougt:we actually need to do that
... there's this idea that the UA will hand a URL to the app that'll
send it to the server
... so the app server now has a URL that it uses to contact the push server
... so when the push happens we need to define the protocal
... we want a default protocol that all can use
... so the app server needs a well known way to talk to the push server
... I want to spec out the wire protocol, and that will be the normative way
... if we don't do that, there will be plenty of different protocols
... and we'll need complex code to handle multiple protocols
... so we want a default, and people can use other stuff so long as they
support that
bryan:many legs to such systems
... leg to leg interop standards, there's app server to push server, but
also push server to push client
... do we want only the first leg to lef?
dougt:I don't think we need the latter leg
testing
<jgraham> Is there any disagreement that's a good idea?
<Ms2ger> jgraham, there's a pointer to some webapps wiki on the agenda
<krisk>http://www.w3.org/wiki/Webapps/April2013Meeting
<jgraham> Yes, so there is
<jgraham> We should kill the wikis entirely and put the site in git,
like everything else
Move to Github
<timeless> scribe: Josh_Soref
<timeless> scribenick: timeless
[ ArtB introduces the room to tobie ]
[ Microsoft, Google, Apple, Toshiba, Samsung ]
ArtB:tobie is a visiting fellow at W3C, sponsored by Facebook
... a month ago, we started moving our tests from Mercurial to GitHub
... html has done that, and other groups are doing it as well
... i'm interested in getting an update on where we are
tobie:hello everyone
... thanks for making time for testing
... 3 things
... to talk about
... one is on the actual move to github of webapps test suite
... i wasn't directly involved, but afaik, everything has moved to
github and is doing fine
... maybe Ms2ger has more input
... or darobin
... the other part of interest
... we have this very big testing effort
... we started planning and budgetting
... but we're waiting for funding to start
... that effort consists of building a good infrastructure to do testing
at w3c
... and also to handle the backlog of testing
... and also to do a better job of keeping up to date in testing
... making testing, things to help build interoperable implementations
... rather than just moving specs along REC track
... do more testing that currently
... don't know if you have specific questions
<Ms2ger> Fully support the comment about REC track
tobie:on planned infrastructure
... good to have questions
ArtB:anyone have questions for tobie ?
[ Silence ]
ArtB:odinho had put together a document describing the overall workflow
... that probably needs to be fleshed out w/ webapps specific information
... Rebecca from TestTheWebForward has put together a document on how
contributors can help
... --
... a thing that wasn't clear to me was how we handle reviews
<jgraham> I hope there isn't "WebApps-specific" information; it should
be the same for all web-platform WGs
ArtB:we're organized a bit differently than the html wg
... we have test facilitators
... krisk is the manager of the html wg test suite
... but we have 10 or 12 volunteers for specific test suites
... a thing we're potentially missing here
... how does a group of people who care about testing get notified when
a submission gets made
... if i'm implementing WebSocket
... maybe i want a notification if a pull request on WebSocket gets made
<Marcos> Zakim: passcode?
ArtB:or maybe i want a notification for all test suites
... can someone explain how this happens/can be managed?
<Ms2ger> You can list yourself as a reviewer for specific dirs in
critic, and then you'll get email about PRs for those dirs
tobie:jgraham notes the system he's promoting solves this problem
... we don't have that capability with github today
<jgraham> GitHub doesn't have any way to handle this as far as I know
ArtB:jgraham are you on the call?
tobie:he isn't
... whether or not we have the right tool for the job
... during transition
<jgraham> We either need to roll our own, or use something pre-existing.
We have critic set up and it solves this as well as several other
problems. I sent an email to public-webapps the other day
tobie:you might be best listening to everything
... and use personal rules
... maybe jgraham can set rules using Critic
<Ms2ger>http://critic.hoppipolla.co.uk/
ArtB:we recorded 7 or 8 actions for darobin, who just re-entered the room
chaals:Critic is a tool Opera developed for code review
<jgraham>http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0364.html
ArtB:what's html wg going to do?
<Ms2ger> Does the HTMLWG do reviews?
ArtB:i'd rather use something that's well tested
darobin:we don't have hard and fast rules
... reviewing are done w/ whatever the reviewer is comfortable
ArtB:is the github review process a PITA?
darobin:i find it ok
... in general, if the review is simple, they do it in github
... for more advanced reviewing, they use critic
... both are available
... you can use one or the other on a per-pull-request basis
ArtB:do we give whomever submits the request?
darobin:i'm letting the reviewer pick what they're most comfortable w/
<Ms2ger> Given the general lack of reviewers, I'd support letting the
reviewer pick
darobin:if we hit issues w/ the tool affecting the submitter, we can
cross that bridge then
<krisk> here is an example of a pull request using
githubhttps://github.com/w3c/web-platform-tests/pull/77
darobin:we're seeing more reviews now
... probably still things to iron out
... but it's improving
ArtB:i agree, it's better now
<hallvord_> I note that Critic is well tested inside Opera :)
ArtB:excellent progress
... i'll look at what odinho wrote
<jgraham> I think common sense works. If you know that the contributor
is new it is better to pick GitHub unless there is an overwhelming
reason not to. For frequent contributers and difficult reviews it just
isn't good enough
<jgraham> (yeah we have used it for tens of thousands of reviews inside
Opera)
ArtB:does anyone object to this model?
tobie:i like what jgraham is saying on irc
... let the reviewers figure it out
chaals:we have critic running inside Yandex, it seems reasonable
<Zakim> Ms2ger, you wanted to suggest moving all the documentation
spread over a dozen W3C wikis into the repo instead
<Ms2ger> That ^
chaals:thanks for volunteering to do that
<Ms2ger> Alright, alright
tobie:that's a plan
... there has been
... one person contributed a lot of documentation to the html test efforts
... i'm in the process of ...
<ArtB>*ACTION:*barstow work with Tobie, Robin, Ms2ger, Odin, etc. to
make sure WebApps' testing workflow is well documented and kept on
GitHub [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action04]
<trackbot> Created ACTION-695 - Work with Tobie, Robin, Ms2ger, Odin,
etc. to make sure WebApps' testing workflow is well documented and kept
on GitHub [on Arthur Barstow - due 2013-05-03].
tobie:collecting up the documentation and putting it into one place
... and there are wikis pointing all over the place
... i'm going to have them redirect to that canonical documentation
ArtB:sounds good to me
... goal is to have as much generic documentation as we can
... and only have one offs if we absolutely need them
... krisk, darobin and I ...
... talked about within webapps's test suite
... i don't think we've done CR branching
... we've had some suites used to exit CR
... we should probably branch
... Web Storage, and Selectors API v1
darobin:yes
ArtB:will the test facilitator do that work?
darobin:it's a single commandline
<tobie>http://www.w3.org/wiki/Testing/Resource_Center_TF/Documentation
<Ms2ger> I hope by "branching" we mean "subsetting"
<ArtB>*ACTION:*create CR branch for Web Storage and Selectors API v1
test suites [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action05]
<trackbot> Error finding 'create'. You can review and register nicknames
at <http://www.w3.org/2008/webapps/track/users>.
<http://www.w3.org/2008/webapps/track/users%3E.>
<Zakim> tobie, you wanted to talk about doc
<darobin> [ Ms2ger: yes]
<tobie>http://www.w3.org/wiki/Testing/Resource_Center_TF/Existing_Documentation
tobie:i dumped two links
... one is documentation of testing efforts
... and one is a list of scattered documents
... if you know of other pages, please add links to the second wiki
krisk:i want to discuss about when things end up in CR branch
... we put things into CR branch and expect them to run test
... in the past, we used approved folder
ArtB:also WebSockets
... you think we should create the branch before interop testing begins?
krisk:sure
<ArtB>*ACTION:*kris create the CR branch for Web Messaging and Web
Sockets test suites [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action06]
<trackbot> Created ACTION-696 - Create the CR branch for Web Messaging
and Web Sockets test suites [on Kris Krueger - due 2013-05-03].
<Zakim> tobie, you wanted to comment on CR branch
tobie:it'd be good if the plan for this was documented somewhere
... i'd like to see it documented, also for my own personal reading
krisk:the CR branch is an indication that the specification is more mature
... and the tests should be more mature
... that's the spirit of CR v. Master
tobie:how do these things go forward?
... do all tests end up in master?
<jgraham> I don't think the tests should be more mature really
tobie:do all tests in CR end up in master?
darobin:the plan is "basically simple"
... we created "master" and "CR" initially
... primarily for specs w/ concurrent versions under developed
... initially for HTML5.0 and HTML5.1
... all news tests go into master
... when you want to flag the fact that you're stabilizing a subset of
the tests for stable
... you merge that subset to CR
... if a group wants to merge at LC instead of CR, they can do that
... it's the stable branch
... No no no no no no, we spent 3 weeks bikeshedding the name
tobie:provided we get funding
... i think we'll try to make a shiny presentation
... and backed by proper tests
<Ms2ger> jgraham, can you elaborate?
chaals:asking jgraham about tests being more mature
... jgraham, what does " I don't think the tests should be more mature
really" mean?
ArtB:i think we're about done on this topic
<Ms2ger> Boo
<jgraham> I mean that as far as possible the tests on CR should just be
the same as those on master, but perhaps not covering new features
<jgraham> Also, I expect the bugs in tests on master to be worked out
much faster. Once we get people importing and running tests. Which isn't
really happeneing yet, and is a big problem.
tobie:have fun with that
chaals:MikeSmith pointed out
... AppCache, AppCache v2, fixing that
... there's a Navigation Controller idea floating around
... Google hasn't provided their proposal, which they promised 6 months ago
... if they submit it, or someone forks it
... and submits it
MikeSmith:i want to point out the thing in the charter w/ the escape clause
... is to move something from the HTML WG
... but Nav Controller isn't AppCache
... it's a superset
... i don't want us to take it on, do the work, and someone by proxy
says "this isn't in scope of your charter"
... "... it isn't the same as AppCache"
chaals:we don't want to take AppCache straight from html
... among the things in Fixing AppCache --- Nav Controller will be a
proposed deliverable
Progress Events
Jungkee:Jungkee from Samsung
<Jungkee>http://www.slideshare.net/jungkees/progress-events-web-apps-f2f-at-san-jose
Jungkee:i made slides for this
<ArtB>ProgressEvent ED
<http://dev.w3.org/2006/webapi/progress/Progress.html>
Jungkee:about status of Progress spec
... it's in CR
... for a while, XHR was the only consumer
... but we have 2 other consumers
... <img> in HTML5.1
... and Messaging API in SysApps WG
... we've taken Ms2ger 's submissions from the mercurial repo
... we've made approved test files w/ test assertions
... i made one ED change, from octet to byte
... octet was a network term
... byte is what's used in XHR
... so this allowed for alignment with that
... Plan: Meet CR exit criteria
... patches in Gecko, WebKit and Blink are in progress
... and recently some have landed
... there are two test files
... Constructor.html and interface.html
<JonathanJ>http://www.w3.org/wiki/Webapps/Interop/ProgressEvents
<Ms2ger>https://wiki.mozilla.org/RapidRelease/Calendar
Jungkee:the bugs should be fixed in Firefox 22
... can we use unstable releases?
ArtB:for Web Storage, we used Firefox Nightlies
Jungkee:my colleague landed patches to WebKit and Blink for Progress
interface items 1 and 6
... Ms2ger left a comment that the outstanding bug in Mozilla is
depending on bug 776864
... there's no progress on that
... once that's fixed, we can meet CR exit criteria
ArtB:thanks
smaug:WebIDL events for Progress bindings will land some time next week
... and then all events will have WebIDL bindings
ArtB:at one point, WebKit was 100% the same as Blink
... every day, that equality becomes less
<smaug> one
ArtB:are they one or two implementations?
chaals:seems to me it depends on what the stuff is
... look at it on a task basis
... webkit and blink are the same on a bunch of stuff
... and different on a bunch of stuff
... if they show plans to diverge, then they're different
... two implementations rule isn't some plan from heaven
... and different people who pick up this spec
... will understand it in the same way
... for now, this is the same thing
... different js engines, running around on webkit based browsers
... they're independent
... if someone writes the patch, and submits it to webkit and blink
... this isn't two implementations
... it'd be the same as if one person implemented it for webkit and gecko
... what do you say?
... this isn't a filling the boxes
... in this case, we'll probably treat them the same
<smaug> brb
Josh_Soref:We have past history
... where browser vendors shipped WebSQL based on a single SQL engine
... and we counted them as a single implementation
lgombos:the javascript engines in WebKit and Blink are different
... your statements make sense today
... but they'll become radically different
Travis:the testcases in IE are reported incorrectly
... i'm getting passes
Jungkee:which version?
Travis:10
ArtB:I used a Lumia WP8 IE
Travis:I'm on the desktop browser
ArtB:did you run the constructor tests as well?
Travis:i think there's a testing error
Jungkee:for IE10, i'll go w/ the desktop version
... For Opera, this was Presto
<krisk> q
<ArtB>*ACTION:*Jungkee update the Progress Events interop data using IE
10 Desktop [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action07]
<trackbot> Created ACTION-697 - Update the Progress Events interop data
using IE 10 Desktop [on Jungkee Song - due 2013-05-03].
Jungkee:but Opera will probably release a browser based on Blink
chaals:that brings us back to the question
... do we accept Opera's implementations giving that they've EOL'd their
project
... they implemented it interoperably in a product designed for the market
... conclusion is that someone sitting down can design it interoperably
based on the spec
... this is a quality measure of the spec
... the tests help you find out if it works right
<krisk> q
krisk:one of the thing we've noticed
... is people reports stuff for IE, and they're wrong
... and they waste a lot of time
... it'd be good for people to contact us
... the vendor should do the reporting
ArtB:good feedback
[ Break ]
<Ms2ger> I don't think it makes sense to limit testing to only the vendor
<Ms2ger> It's much easier for one person to just run all the browsers
they've got available
XHR Status
<Jungkee>http://www.slideshare.net/jungkees/xhr-webappsf2fsanjose
Jungkee:Opera submitted quite a few test cases
... 92
... along w/ 28 from MS and 3 from Ms2ger
... we have thin coverage
... and the tests have moved to github
... there were some missing files in the resource folder
... there were 14 commits from last November in WHATWG
chaals:the differences,
... is there diverging?
Jungkee:they split URL spec out
... some cleanups, and some stream response types
... there were stream response types in the spec before last TPAC
... when i checked whatwg, stream response was removed a few weeks ago
chaals:do you think we'll do something different?
Jungkee:we think we need to align the spec as much as possible
... we have 13 unresolved bugs
... we plan to branch a REC track version
<hallvord_> I'm half-way through a review of Opera's tests
Jungkee:to finalize IP commitment
... it's widely implemented
... w/ defacto implementation
... it'd be really nice if the chairs have comments about this
chaals:we think it's really cool
... it's useful to get a v1 spec finished
... XHR level 1 would be useful
<hallvord_> the spec has shifted a bit regarding details, so the tests
were in worse shape than I expected
chaals:out of scope: CORS, data: url, HTTP auth, overrideMimeType, and
progress events
<hallvord_> (sorry to interject stuff while you're probably having a
conversation..)
chaals:there's a controversial discussion on http auth
... there's a XHR bleeding edge
... goal is to get it to REC around TPAC 2014
... working on issues
... expedite interop testing
... testing results
... the test results are different browser to browser
... tentatively titled XHR level 2
... we're open to discussion of the title
<hallvord_> (some of the differing test results are due to test bugs!)
chaals:scope includes incremental features. stream response types
... major issues:
... 13
<Ms2ger> XHR level 1?
<Ms2ger> That means we're full circle, I guess
<chaals>open issues
<https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&bug_status=NEW&component=XHR&list_id=9031>
<hallvord_>https://github.com/w3c/web-platform-tests/pull/103-> known
test bugs right now
Jungkee:ovverridemimetype, http auth
... loading and DOM
... and exceptions/or not
... for credentials, there are a few ways
... providing user/auth
... and including in url
... for stream data type
... - i don't know how it goes
... possibly related to MSE ?
... - from HTML WG
... i don't think the other issues are really critical
... we haven't worked on those issues this quarter
... committed to looking in a few months
... back to level 1 version
... there was a discussion in HTML WG
... of publishing a TR as LC and FPWD
... i think for stable
chaals:we already have a FPWD of XHR
... so it's a normal LC
... first already exists
... that makes life simple
... June or July for XHR level 1 LC
... questions?
... seems clear and sensible to me
... any other issues we should have covered and haven't yet?
... are we going to go on strike?
... chaals: you're french darobin, it's not strike, it's summer time
... then i believe we're at the end of our agenda
... i'd like to thank Josh_Soref for scribing
[ Applause ]
chaals:i'd like to thank ArtB who was here for all the of the real meaning
... and Yves
... we're very thankful to PayPal and Daniel_Austin
... and we'll see you all at TPAC
... there's Lunch outside
trackbot, end meeting
<smaug> thanks all
trackbot, start meeting
<Ms2ger> More mailing lists?
Coordination (TC39)
<Ms2ger> That'll solve everything
chaals:there was a request from TC39
... on public-script-coord@
... when we update apis
... they asked us to ping that list
... to ask if it was a really sensible API
... following the right kind of cookbooks
... and processes
... the chairs could be made responsible for sending a note to the list
... every time we have a new api to that list
... we also have a `api cookbook`
... on designing apis on things you shouldn't do
... i believe there's a cookbook around or two
... maybe we should look at taking it up
darobin:there is a cookbook in github
... and it has content
... but it needs work
... it needs updates
... hober mentioned Futures
... i know Jungkee was working on it
... maybe if there are other contributors who want to help out
... it can be taken forward and published
... it's worth involving the new TAG in the cookbook
Yves:it has people from TC39
chaals:i sent an email to SysApps in particular
<Jungkee>http://www.w3.org/TR/api-design/
chaals:but yeah, this isn't WebApps and TC39
<darobin>https://github.com/darobin/api-design-cookbook/
chaals:there are other groups around W3
... can you action me to send this to the other groups
... and to those who don't read emails
<darobin>*ACTION:*Chaals to send a note to chairs indicating the TC39
API review policy [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action08]
<trackbot> Created ACTION-698 - Send a note to chairs indicating the
TC39 API review policy [on Charles McCathie Nevile - due 2013-05-03].
chaals:this came from a discussion between TC39 and us, on
public-script-coord@
... they said, yes please, that'd be helpful
Daniel_Austin:we're technically members, we can help
chaals:thank you Daniel_Austin for hosting
[ Applause ]
Daniel_Austin:i got an email from someone @ PayPal, and i was authorized
to do this again next year
... we'll try to avoid Bring your kids to work day
... we had a bet as to which kids would be best behaved
chaals:thanks very much
<smaug> thanks
trackbot, end meeting
Summary of Action Items
*[NEW]**ACTION:*barstow announce the WG will meet during TPAC 2013 in
November [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action01]
*[NEW]**ACTION:*barstow work with Tobie, Robin, Ms2ger, Odin, etc. to
make sure WebApps' testing workflow is well documented and kept on
GitHub [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action04]
*[NEW]**ACTION:*Chaals to send a note to chairs indicating the TC39 API
review policy [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action08]
*[NEW]**ACTION:*charles prepare a Draft charter update for the WG to
review [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action03]
*[NEW]**ACTION:*charles to be the default Editor of URL spec [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action02]
*[NEW]**ACTION:*create CR branch for Web Storage and Selectors API v1
test suites [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action05]
*[NEW]**ACTION:*Jungkee update the Progress Events interop data using IE
10 Desktop [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action07]
*[NEW]**ACTION:*kris create the CR branch for Web Messaging and Web
Sockets test suites [recorded
inhttp://www.w3.org/2013/04/26-webapps-minutes.html#action06]
[End of minutes]
------------------------------------------------------------------------
Received on Saturday, 27 April 2013 13:55:35 UTC