Re: Draft minutes: 26 April 2013 f2f meeting

<person> = comments directly from people on IRC
person: = comments transcribed from people live in the room or on the phone.


On Sat, Apr 27, 2013 at 8:04 PM, Rick Waldron <waldron.rick@gmail.com>wrote:

> 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.
>
>