Re: Draft minutes: 26 April 2013 f2f meeting

This is hard to follow... Almost like two different discussions are
happening at the same time. One discussion has "person: ..." the other
"<person> ..."

Rick

On Saturday, April 27, 2013, Arthur Barstow wrote:

> 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<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<http://www.w3.org/wiki/Webapps/April2013Meeting>
> >
>
> See also:IRC log <http://www.w3.org/2013/04/26-**webapps-irc<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<http://www.w3.org/2013/04/26-webapps-minutes.html#agenda>
> >
>     1. testing <http://www.w3.org/2013/04/26-**webapps-minutes.html#item01<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<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<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<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<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<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 <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 <
> http://www.w3.org/wiki/**Webapps/Charter<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<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<http://www.w3.org/wiki/Webapps/April2013Meeting>
>
> <ArtB>pending Charter updates <http://www.w3.org/wiki/**Webapps/Charter<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<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 <http://www.w3.org/2004/01/pp-**
> impl/42538/status#current-**disclosures<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<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 <https://dvcs.w3.org/hg/push/**
> raw-file/default/index.html<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<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<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.