IRC log of tagmem on 2013-12-19

Timestamps are in UTC.

17:53:03 [RRSAgent]
RRSAgent has joined #tagmem
17:53:03 [RRSAgent]
logging to http://www.w3.org/2013/12/19-tagmem-irc
17:53:08 [Zakim]
TAG_Weekly()1:00PM has now started
17:53:14 [Zakim]
+Bryan_Sullivan
17:53:53 [bryan]
bryan has joined #tagmem
17:54:19 [dka]
dka has joined #tagmem
17:54:59 [dka]
trackbot, this will be tag
17:54:59 [trackbot]
Sorry, dka, I don't understand 'trackbot, this will be tag'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
17:55:08 [dka]
trackbot, start meeting
17:55:10 [trackbot]
RRSAgent, make logs public
17:55:12 [trackbot]
Zakim, this will be TAG
17:55:12 [Zakim]
ok, trackbot, I see TAG_Weekly()1:00PM already started
17:55:13 [trackbot]
Meeting: Technical Architecture Group Teleconference
17:55:13 [trackbot]
Date: 19 December 2013
17:55:42 [Zakim]
+plinss
17:55:50 [dka]
regrets+: Henry Thompson
17:56:38 [Zakim]
+dka
17:57:24 [twirl]
twirl has joined #tagmem
18:00:08 [efullea]
efullea has joined #tagmem
18:00:09 [dka]
zakim, who is here?
18:00:09 [Zakim]
On the phone I see Bryan_Sullivan, plinss, dka
18:00:11 [Zakim]
On IRC I see efullea, twirl, dka, bryan, RRSAgent, Zakim, timbl, marcosc, wycats_, slightlyoff, Yves, trackbot, plinss
18:00:46 [Zakim]
+??P9
18:00:49 [JeniT]
JeniT has joined #tagmem
18:01:08 [Zakim]
+Yves
18:01:28 [ArtB]
ArtB has joined #tagmem
18:01:34 [Zakim]
+[IPcaller]
18:01:41 [Zakim]
+ +34.91.432.aaaa
18:01:44 [ArtB]
zakim, what's the code?
18:01:44 [Zakim]
the conference code is 0824 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), ArtB
18:01:54 [ArtB]
zakim, call art_barstow
18:01:54 [Zakim]
I am sorry, ArtB; I do not know a number for art_barstow
18:02:23 [plinss]
zakim, aaaa is efullea
18:02:23 [Zakim]
+efullea; got it
18:02:25 [Zakim]
+Art_Barstow
18:03:15 [chaals]
chaals has joined #tagmem
18:03:33 [dka]
Chair: Peter
18:03:49 [chaals]
zakim, code?
18:03:49 [Zakim]
the conference code is 0824 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), chaals
18:04:13 [Zakim]
+[IPcaller]
18:04:18 [chaals]
zakim, [ip is me
18:04:18 [Zakim]
+chaals; got it
18:04:21 [dka]
Scribe: Dan
18:04:26 [dka]
ScribeNick: dka
18:04:33 [Zakim]
+TimBL
18:05:25 [bryan]
eduardo, are you OK with me forwarding your comments to the Push API draft comments to the www-tag list along with the rest of my responses?
18:05:35 [efullea]
yes
18:05:37 [slightlyoff]
heya
18:05:40 [slightlyoff]
on the way
18:05:43 [slightlyoff]
apologies for being late
18:05:57 [chaals]
zakim, agenda?
18:05:57 [Zakim]
I see nothing on the agenda
18:06:06 [dka]
Peter: Starting the discussion on Push. Welcome to our invited guests.
18:06:09 [chaals]
rrsagent, draft minutes
18:06:09 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/12/19-tagmem-minutes.html chaals
18:06:35 [dka]
Bryan: I am going to send a note to the www-tag list with my comments on the draft comments prepared already.
18:06:52 [ArtB]
-> http://lists.w3.org/Archives/Public/www-tag/2013Dec/0028.html Draft for note to send to Push API editors/authors
18:07:05 [dka]
Topic: Push
18:07:14 [dka]
Bryan: Shall I give my responses to the TAG feedback?
18:07:18 [dka]
Peter: yes
18:07:43 [Zakim]
+??P19
18:07:46 [twirl]
https://github.com/w3ctag/spec-reviews/blob/c218958ce2c9b655282bd1ebdbe93e8902b423e1/2013/08/Push%20API.md
18:07:58 [slightlyoff]
Zakim: ??P19 is me
18:08:02 [dka]
Bryan: the first issue was that the concepts are unclear - things such as : why is a push service needed? in general the need is understood by app developers in the market.
18:08:30 [dka]
Bryan: we didn't feel it was necessary to explain all that. We did have some use cases that we brought to the webapps discussion - I put a reference to those use cases.
18:08:36 [chaals]
rrsagent, make log public
18:08:44 [dka]
+1 to the importance of having push functionality in the Web platform, by the way.
18:09:25 [dka]
Alex: It's not necessarily unclear but it seems there has been some debate about e.g. the wired protocol...
18:09:38 [ArtB]
https://dvcs.w3.org/hg/push/raw-file/default/index.html -> Push API (Editor's Draft)
18:09:44 [dka]
Bryan: I provided a link to the use case we used in the webapps rechartering.
18:09:48 [chaals]
[+1 to linking to explicit use cases]
18:10:18 [dka]
Bryan: 2nd thing - what is "how should the app server deal with" mean?
18:10:19 [slightlyoff]
go ahead marcosc
18:10:28 [slightlyoff]
there's a second issue that I'll bring up in a second
18:10:49 [dka]
Sergey: the over the air protocol. How should a web page know how to negotiate with a push server?
18:11:41 [dka]
Bryan: There are a variety of ways to interact with push systems e.g. the urban airship protocol. Currently the wire protocol has not been in scope for this API.
18:12:17 [dka]
Alex: I guess I can buy that but I am curious to know how the message delivery is meant to work regarding the execution context.
18:12:42 [dka]
Alex: let's say I've got a way of targeting some application on the device and the system delivering the message thinks it knows how to do it, what is the exec context meant to be?
18:12:52 [dka]
Alex: what about when the document isn't open, for example?
18:13:37 [dka]
Bryan: in that case a webapp will make a registration. based on the reg object created, the user agent will deliver the notification to a particular javascript function. Presumably the code that will execute is still in the dom.
18:13:42 [dka]
Alex: how does that happen?
18:14:04 [dka]
Bryan: that's an implementation decision. In prototype implementations we'll figure out how that works.
18:14:16 [dka]
Bryan: could work with service worker.
18:14:47 [dka]
Alex: Service worker is like web worker. It can live disconnected from documents. It's usually invoked by innovation to a url [pattern].
18:15:07 [dka]
Alex: anything within that pattern can invoke that service worker.
18:15:11 [dka]
Alex: it's not persistent.
18:15:30 [dka]
Alex: you could deliver [push] messages to a registered service worker.
18:16:12 [Zakim]
-twirl
18:16:19 [dka]
Eduardo: the current draft is based on system messages defined by sysapps working group.
18:16:27 [dka]
Eduardo: but that this work has been discontinued.
18:16:29 [Zakim]
+??P9
18:16:44 [dka]
Alex: we should make sure that we have a solution for this to meet the criteria for a good api.
18:16:46 [dka]
Bryan: I agree.
18:17:07 [dka]
Bryan: Next question - what info is passing through the push service and how is the UA authenticated?
18:17:24 [dka]
Bryan: the current version is now just a trigger.
18:17:39 [dka]
Bryan: anything delivered between the push server to the user agent is not described in the spec?
18:17:44 [dka]
Sergey: then what spec?
18:18:06 [slightlyoff]
bryan: I can agree with that as a decent place to be with this. Not sure you need to spec out all of the device APIs there.
18:18:28 [dka]
Bryan: there are a variety of specifications. We reference a couple of them. But it's up to the implementation of the device and the user agent. This is only an API providing access to a service. Doesn't depend on a particular service design.
18:19:00 [slightlyoff]
twirl: it's pretty clear they aren't defining any of that?
18:19:02 [dka]
Sergey: do we allow a user to change a push server? Is it possible? Does it work like Jabber? If we design it that way then we must define the protocol.
18:19:15 [dka]
Bryan: it's possible to switch bearers.
18:19:34 [dka]
... but we don't get into those details.
18:20:15 [dka]
Alex: Maybe something that prevent this question from coming up would be informative text giving an example configuration between a device and a network.
18:20:35 [dka]
Bryan: as long as we can do that without being slanted towards an implementaiton.
18:21:02 [dka]
Alex: I'm not worried about non-normative / normative but we should have text saying "for example... it could work like this:..."
18:21:16 [dka]
... there is nothing in your API now that would suggest one implementation over another.
18:21:46 [dka]
Sergey: It's hard to imagine how to write a web app to work with push API. I understand all the answers can't be in the spec but ...
18:21:58 [dka]
Alex: [we don't need the whole stack]
18:22:31 [dka]
Bryan: I could describe a sample implementation.
18:22:55 [dka]
Eduardo: Firefox OS is implementing this Api so this is a reference implementation.
18:23:00 [slightlyoff]
exciting!
18:23:05 [ArtB]
Is there any other impl in progress?
18:23:13 [dka]
Bryan: hopefully the geeks phone device I just got supports it so I can test it.
18:23:35 [slightlyoff]
how persistent?
18:23:46 [dka]
Bryan: registrations are unique to each webapp instance.
18:23:54 [slightlyoff]
and what's a webapp instance? a tab? a document?
18:24:02 [dka]
Bryan: it's the user agent's responsibility to store them as registration objects and we don't specify how.
18:24:10 [slightlyoff]
got it
18:24:13 [dka]
Bryan: it could be that service worker gives us something there.
18:24:51 [dka]
Bryan: next - what is a webapp in the sense of the spec? It's a URL with a domain, a document obtained from that with a DOM object and after that a unique object in the user agent. It's the same as any other case.
18:25:12 [dka]
Alex: You're creating leeway for user agent to create these documents which may match the registration.
18:25:53 [dka]
Alex: let's say I go example.com/app and I open up in 2 tabs - then I open up a sub-document, now 3 tabs - two of them looking at the same document... what happens?
18:26:28 [dka]
Bryan: we have all the tools for that... they have the ability to delegate the first one in as the entry point to push using shared messaging...
18:26:46 [dka]
Bryan: you don't have to share. you don't have to broadcast. If each one wants to create its own push registration it can.
18:27:04 [dka]
Bryan: the registration is bound to a particular webapp instance.
18:27:10 [dka]
Sergey: a particular URL or not?
18:27:33 [dka]
Bryan: invoked through a URL but then becomes a structure within the DOM - this is what the registration is against.
18:28:08 [dka]
Alex: If we come up with a design with service worker we can explain what that means in terms of [service worker].
18:28:19 [dka]
Alex: let's continue to talk about it and iterate on it.
18:28:24 [dka]
Bryan: sounds good.
18:28:37 [dka]
Bryan: an example of a multiple app design might be useful as well.
18:28:58 [dka]
Bryan: how should the user agent invoke an active webapp? could be with service worker...
18:29:15 [dka]
Sergey: invoking an app doesn't mean that browser opens new tab - so how should it be invoked?
18:29:41 [dka]
Alex: thats' kind of what we're talking about - how will delivery happen when the user doesn't have a document...?
18:29:52 [dka]
Alex: you're tied to documents in a way that is unfriendly.
18:30:02 [dka]
Alex: if we figure that out we can get a solution here.
18:30:28 [dka]
Bryan: question we need to get to - how is a webapp constructed and how is it reconstructed when it needs to be reinvoked?
18:30:49 [dka]
Alex: I want to express my enthusiasm for getting this capability into the platform.
18:31:29 [dka]
Bryan: How to invoke a webapp that's using history API -
18:31:53 [dka]
Bryan: does the history manipulation have the ability to change a registration? I don't think it does.
18:31:56 [Zakim]
-twirl
18:32:08 [Zakim]
+??P9
18:32:09 [dka]
Bryan: "express permission" needs to be clarified.
18:32:15 [Zakim]
-JeniT
18:32:29 [JeniT]
JeniT has left #tagmem
18:32:43 [dka]
Bryan: we are channeling this discussion we've had over a long time - how do you describe the need to get user opt-in for an app having access to an API that might be privacy or security sensititive.
18:33:00 [dka]
... we're just saying the user must be engaged in the decision to authorize access.
18:34:13 [dka]
Bryan: "no modification error" needs clarification. I think the spec clarifies that.
18:34:44 [dka]
Bryan: if the request doesn't relate to an active push registration then this error is thrown.
18:35:00 [dka]
Sergey: the unregister might be rejected [?]
18:35:35 [dka]
Bryan: if there is a sync error then the webapp knows - can invoke through its app ID -
18:36:01 [dka]
Sergey: the name is wrong - that is some unknown error. At the moment it seems the user could disallow apps to register...
18:36:23 [dka]
Eduardo: maybe there is a better suggestion we can change it....
18:36:35 [dka]
Bryan: we need to explain further the role of this ...
18:36:48 [dka]
Bryan: any suggestions for a different name for the error would be useful.
18:37:06 [dka]
Bryan: a number of suggesttions for push manager...
18:37:31 [dka]
Bryan: access granting and push manager register are bound together.
18:37:44 [dka]
Bryan: can we ask permission in one interface and based on the result register in a different?
18:38:19 [dka]
Eduardo: actually the way the implementation should work is - you don't need to ask for explicit permission every time - once the user has given access then you don't need to ask for permission.
18:38:39 [dka]
Eduardo: as for whether to split it, it hasn't been considered. I need to understand the advantages / benefits.
18:39:05 [dka]
Sergey: first of all I don't like way UA asks permission....
18:39:17 [dka]
Alex: it seems it's the UA's job to mediate that permissions requests.
18:39:28 [slightlyoff]
hey all, I really need to apologize...I need to get to another meeting
18:39:51 [dka]
Sergey: it's logical - to ask permission once - that is concealed from the web developer. That leads to odd behavior when you need to ask permission again.
18:40:05 [dka]
Alex: the required permission should be async. Could create permission or not...
18:40:21 [dka]
Sergey: logic should be obvious but not concealed inside push manager registry.
18:40:34 [dka]
Alex: API should request some permission and hand you back a promise.
18:40:55 [dka]
Alex: Async nature of the operation gives the UA the option to prompt or not.
18:41:02 [Zakim]
-Art_Barstow
18:41:18 [dka]
Bryan: We differentiate permission from API access.
18:41:38 [Zakim]
-??P19
18:42:10 [dka]
Sergey: there is another issue with the errors.
18:42:16 [dka]
Bryan: It's a good point and I noted that.
18:43:25 [dka]
Bryan: webapps know which registrations belong to them.
18:43:42 [dka]
Bryan: if you have multiple instances you can use a shared worker if you are concerned about too much asking permission.
18:44:14 [dka]
Sergey: if we say that user agent would ask permission each time then it would be very strange behaviour.
18:44:27 [dka]
Bryan: the intent is not to over-prompt the user for permission.
18:46:05 [dka]
Eduardo: I think the different registrations can be differentiated with the push registration ID.
18:46:15 [dka]
... this is unique to the each registration.
18:46:36 [dka]
... notifications associated to each registration are differentiated by ID.
18:47:08 [dka]
Bryan: then a number of suggestions for renaming. In general they are OK.
18:47:16 [dka]
Eduardo: no it would't be a problem to change the naming.
18:47:36 [Zakim]
-twirl
18:47:55 [Zakim]
+??P9
18:48:07 [dka]
Bryan: the question of routing of messages as an exercise for developers - and the binding of documents to URL space - I think this understood for things browsed.
18:48:56 [dka]
... in general a push system is different in that it's server-initiaitve. It's bound to the URL that the webapp was invoked from because that webapp creates the registration.
18:49:06 [dka]
... hopefully in my email response this is clarified.
18:49:39 [dka]
... I think it would be great to have concrete examples and I can provide those for the ones I'm familiar with.
18:50:33 [dka]
Tim: it can't be used in any context
18:50:44 [dka]
Bryan: it probably does;t have any meaning in any other context.
18:51:24 [dka]
Bryan: it's a URL exposed by a push server. The registration ID is a string relating to the webapp instance that made the request. Those things don't have a meaning outside of a specific push service.
18:52:10 [dka]
Bryan: we might have some new specs come out on these if we can people can bring that to the table.
18:52:26 [dka]
Bryan: next question - related to the idea of a message queue.
18:52:48 [dka]
... why not use DOM event model?
18:53:14 [dka]
Eduardo: this is based on the system messages design.
18:53:34 [dka]
... seems system messages are going to be discontinued. So we need to find an altertnative.
18:53:54 [dka]
Bryan: I agree we should use tired and true eventing interfaces.
18:54:35 [dka]
Bryan: final question - it's unclear from the code examples how this is meant to be invoked.
18:54:41 [dka]
Bryan: it's largely left out of scope.
18:54:57 [dka]
Bryan: the system being the push server and the user agent are assumed to know about eachother.
18:55:06 [dka]
... that might in the end rely on service workers.
18:55:20 [dka]
... but it's considered to be out of scope.
18:55:50 [dka]
Peter: it's seems like the kind of things that service workers would help out with but to me it seems like relying on magic.
18:56:18 [dka]
... if you think about a push message delivered to the platform and the browser isn't running. what happens? Should that be part of the registration?
18:56:38 [Zakim]
-dka
18:56:41 [dka]
Bryan: that is one of the permutations we are going to haver to cover.
18:56:57 [Zakim]
+dka
18:57:20 [dka]
Peter: anything else?
18:57:47 [dka]
Sergey: many things more clear than before. I will edit the review on github thought i still have questions and I need time to formulate.
18:58:18 [dka]
I suggest we add this to our f2f agenda and maybe we can ask Eduardo and Bryan to call in?
18:59:01 [dka]
Peter: thanks all for joining us.
18:59:10 [dka]
... we need to keep lines of communication open.
18:59:21 [dka]
... we have a f2f coming up in a couple weeks.
18:59:24 [dka]
Jan 7-9
19:00:16 [dka]
Eduardo: yes it's ok.
19:00:24 [dka]
Bryan: i'l be at CES but I'll do my best.
19:00:37 [Zakim]
-Bryan_Sullivan
19:00:38 [Zakim]
-efullea
19:00:43 [dka]
Peter: Tim did you want to bring up http 209?
19:00:46 [dka]
Topic 209
19:01:01 [Zakim]
-chaals
19:01:07 [dka]
tim: something the tag talked about way back. Linked to http-range-14.
19:01:18 [dka]
... this shouldn't involve too much philosophy.
19:01:30 [Zakim]
-twirl
19:01:43 [dka]
... there is return code used for LD 303 - you've asked for something I'm not going to give you but I'll give you info about it.
19:02:09 [dka]
... in LD it happens when X is some abstract thing and Y is a document about the thing.
19:02:37 [dka]
... the time it would be useful - you've asked for a database but I'm going to give you info for querying it.
19:03:20 [dka]
... LDP group is one that is doing read-write access to stores. They've got a paging system to ask for a piece of data and if it's too big then you get the first page.
19:04:09 [dka]
... another case: you asked for this but it's a very small thing. I'm giving you information about a bunch of other things as well.
19:04:14 [ht]
ht has joined #tagmem
19:04:32 [dka]
... all this happens with a 303. 303s involve a http roundtrip. slows things down.
19:05:10 [dka]
... so the conclusion is - having another 20x code - a 209. this is equivalent of a 303 followed by a 200.
19:05:17 [dka]
... this will speed things up a lot.
19:05:58 [dka]
... reason I'm bringing to the TAG - the LDP working group needs this ... but could be useful to anyone using 303.
19:06:28 [dka]
... [hasn't happened becasuse] defining a new return code would be trouble... we'll have to make an RFC...
19:06:52 [dka]
... I feel it would be good for the web to have a new 20x code ...
19:07:50 [dka]
... [has been some disconnect between LD people / semantic web people / protocol people ]
19:08:15 [dka]
... so what should we do? One possibility is for LDP to ask Yves nicely to do this - as an RFC>
19:08:24 [dka]
... and get this adopted.
19:08:36 [dka]
... or maybe we should get write an extension spec.
19:08:56 [Yves]
http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
19:08:57 [dka]
... one possiblity is to do ths...
19:09:16 [dka]
Yves: first the http status code registry requires IETF consensus - so you need an rfc.
19:09:28 [dka]
Tim: does it have a way of reserving a code?
19:09:31 [dka]
Yves: no.
19:09:38 [dka]
Yves. Non.
19:10:10 [dka]
Yves: ...but chances are high that if you have a draft out there then it won't be taken.
19:10:38 [dka]
Suggest now that we've laid out the problem we make this part of our discussion on data on the Web at the next TAG f2f....
19:11:04 [dka]
Yves: the best is to have the group interested in working on that draft (as an RFC) what they want to have.
19:11:19 [dka]
... then get feedback from IETF community.
19:11:42 [dka]
Peter: should we discuss during the data on the web topic at the f2f.
19:11:47 [dka]
Tim: yes I'm happy with that.
19:12:22 [dka]
Dan: could be useful to have some draft text as a straw man.
19:12:39 [dka]
Tim: yes - it sounds like a small thing but ...
19:12:49 [dka]
... something like 233 or somehting....
19:12:57 [Yves]
example of a small rfc to add a status code: http://tools.ietf.org/html/draft-reschke-http-status-308-07
19:13:34 [dka]
One question I have: does it have non-data non-LD use cases?
19:14:25 [dka]
Tim: what's interesting about is the machine understanding the relationship between the two documents.
19:14:40 [dka]
Tim: if you're dealing with a human being you just get a 200.
19:15:19 [dka]
Dan: would it be useful in a httprequest context?
19:15:39 [dka]
Tim: it would be more useful in machine-readable context.
19:16:22 [dka]
Tim: it would only work if you had an expect ion fron the server that the clinet would understand it .
19:16:42 [dka]
Peter: you also mentioned a case using it for pagination.
19:17:00 [dka]
... that could have broader use for API calls as well...
19:18:23 [dka]
Tim: another use - [in captive portals]
19:19:15 [dka]
Tim: I think the 209 is a simple thing to push through.
19:20:29 [dka]
[discussion / rant on captive portals and the evil of...]
19:22:20 [Zakim]
-dka
19:22:23 [Zakim]
-Yves
19:22:25 [Zakim]
-plinss
19:22:34 [dka]
Adjourned
19:22:41 [dka]
rrsaegent, make minutes
19:22:51 [dka]
rrsagent, make minutes
19:22:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/12/19-tagmem-minutes.html dka
19:22:56 [dka]
rrsagent, make logs public
19:23:46 [dka]
rrsagent, make minutes
19:23:46 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/12/19-tagmem-minutes.html dka
19:35:00 [Zakim]
disconnecting the lone participant, TimBL, in TAG_Weekly()1:00PM
19:35:01 [Zakim]
TAG_Weekly()1:00PM has ended
19:35:01 [Zakim]
Attendees were Bryan_Sullivan, plinss, dka, twirl, Yves, JeniT, +34.91.432.aaaa, efullea, Art_Barstow, [IPcaller], chaals, TimBL
20:09:43 [dka]
dka has joined #tagmem
20:17:14 [JeniT]
JeniT has joined #tagmem
20:28:44 [timbl]
timbl has joined #tagmem
20:58:34 [dka]
dka has joined #tagmem
21:23:00 [Zakim]
Zakim has left #tagmem
22:19:00 [chaals]
chaals has left #tagmem