Web Applications WG F2F Meeting -- 26 Apr 2013

<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 in http://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

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 in http://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

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 in http://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

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 w3cmemes http://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

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 github https://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 in http://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 in http://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>.

<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 in http://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

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 in http://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

<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 in http://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

- DRAFT -

Web Applications WG F2F Meeting

26 Apr 2013

Attendees

Contents

testing

Move to Github

Progress Events

XHR Status

Coordination (TC39)

Summary of Action Items

Scribe.perl diagnostic output