W3C

Technical Architecture Group Teleconference

19 Dec 2013

See also: IRC log

Attendees

Present
Daniel Appelquist, Peter Linss, Yehuda Katz, Yves Lafon, Alex Russell, Sergey Konstantinov, Jeni Tennison, Tim Berners-Lee
Invited Guests
Art Barstow, Bryan Sullivan, Eduardo Fullea, Charles McCathieNevile
Regrets
Anne van Kesteren, Henry Thompson
Chair
Peter Linss
Scribe
Daniel Appelquist

Contents


Push

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

<efullea> yes

<slightlyoff> heya

<slightlyoff> on the way

<slightlyoff> apologies for being late

Peter: Starting the discussion on Push. Welcome to our invited guests.

Bryan: I am going to send a note to the www-tag list with my comments on the draft comments prepared already.

<ArtB> Draft for note to send to Push API editors/authors

Bryan: Shall I give my responses to the TAG feedback?

Peter: yes

<twirl> https://github.com/w3ctag/spec-reviews/blob/c218958ce2c9b655282bd1ebdbe93e8902b423e1/2013/08/Push%20API.md

<slightlyoff> Zakim: ??P19 is me

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

+1 to the importance of having push functionality in the Web platform, by the way.

Alex: It's not necessarily unclear but it seems there has been some debate about e.g. the wired protocol...

<ArtB> https://dvcs.w3.org/hg/push/raw-file/default/index.html -> Push API (Editor's Draft)

Bryan: I provided a link to the use case we used in the webapps rechartering.

<chaals> [+1 to linking to explicit use cases]

Bryan: 2nd thing - what is "how should the app server deal with" mean?

<slightlyoff> go ahead marcosc

<slightlyoff> there's a second issue that I'll bring up in a second

Sergey: the over the air protocol. How should a web page know how to negotiate with a push server?

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.

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.
... 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?
... what about when the document isn't open, for example?

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.

Alex: how does that happen?

Bryan: that's an implementation decision. In prototype implementations we'll figure out how that works.
... could work with service worker.

Alex: Service worker is like web worker. It can live disconnected from documents. It's usually invoked by innovation to a url [pattern].
... anything within that pattern can invoke that service worker.
... it's not persistent.
... you could deliver [push] messages to a registered service worker.

Eduardo: the current draft is based on system messages defined by sysapps working group.
... but that this work has been discontinued.

Alex: we should make sure that we have a solution for this to meet the criteria for a good api.

Bryan: I agree.
... Next question - what info is passing through the push service and how is the UA authenticated?
... the current version is now just a trigger.
... anything delivered between the push server to the user agent is not described in the spec?

Sergey: then what spec?

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

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.

<slightlyoff> twirl: it's pretty clear they aren't defining any of that?

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.

Bryan: it's possible to switch bearers.
... but we don't get into those details.

Alex: Maybe something that prevent this question from coming up would be informative text giving an example configuration between a device and a network.

Bryan: as long as we can do that without being slanted towards an implementaiton.

Alex: I'm not worried about non-normative / normative but we should have text saying "for example... it could work like this:..."
... there is nothing in your API now that would suggest one implementation over another.

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

Alex: [we don't need the whole stack]

Bryan: I could describe a sample implementation.

Eduardo: Firefox OS is implementing this Api so this is a reference implementation.

<slightlyoff> exciting!

<ArtB> Is there any other impl in progress?

Bryan: hopefully the geeks phone device I just got supports it so I can test it.

<slightlyoff> how persistent?

Bryan: registrations are unique to each webapp instance.

<slightlyoff> and what's a webapp instance? a tab? a document?

Bryan: it's the user agent's responsibility to store them as registration objects and we don't specify how.

<slightlyoff> got it

Bryan: it could be that service worker gives us something there.
... 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.

Alex: You're creating leeway for user agent to create these documents which may match the registration.
... 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?

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...
... you don't have to share. you don't have to broadcast. If each one wants to create its own push registration it can.
... the registration is bound to a particular webapp instance.

Sergey: a particular URL or not?

Bryan: invoked through a URL but then becomes a structure within the DOM - this is what the registration is against.

Alex: If we come up with a design with service worker we can explain what that means in terms of [service worker].
... let's continue to talk about it and iterate on it.

Bryan: sounds good.
... an example of a multiple app design might be useful as well.
... how should the user agent invoke an active webapp? could be with service worker...

Sergey: invoking an app doesn't mean that browser opens new tab - so how should it be invoked?

Alex: thats' kind of what we're talking about - how will delivery happen when the user doesn't have a document...?
... you're tied to documents in a way that is unfriendly.
... if we figure that out we can get a solution here.

Bryan: question we need to get to - how is a webapp constructed and how is it reconstructed when it needs to be reinvoked?

Alex: I want to express my enthusiasm for getting this capability into the platform.

Bryan: How to invoke a webapp that's using history API -
... does the history manipulation have the ability to change a registration? I don't think it does.
... "express permission" needs to be clarified.
... 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.
... we're just saying the user must be engaged in the decision to authorize access.
... "no modification error" needs clarification. I think the spec clarifies that.
... if the request doesn't relate to an active push registration then this error is thrown.

Sergey: the unregister might be rejected [?]

Bryan: if there is a sync error then the webapp knows - can invoke through its app ID -

Sergey: the name is wrong - that is some unknown error. At the moment it seems the user could disallow apps to register...

Eduardo: maybe there is a better suggestion we can change it....

Bryan: we need to explain further the role of this ...
... any suggestions for a different name for the error would be useful.
... a number of suggesttions for push manager...
... access granting and push manager register are bound together.
... can we ask permission in one interface and based on the result register in a different?

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.
... as for whether to split it, it hasn't been considered. I need to understand the advantages / benefits.

Sergey: first of all I don't like way UA asks permission....

Alex: it seems it's the UA's job to mediate that permissions requests.

<slightlyoff> hey all, I really need to apologize...I need to get to another meeting

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.

Alex: the required permission should be async. Could create permission or not...

Sergey: logic should be obvious but not concealed inside push manager registry.

Alex: API should request some permission and hand you back a promise.
... Async nature of the operation gives the UA the option to prompt or not.

Bryan: We differentiate permission from API access.

Sergey: there is another issue with the errors.

Bryan: It's a good point and I noted that.
... webapps know which registrations belong to them.
... if you have multiple instances you can use a shared worker if you are concerned about too much asking permission.

Sergey: if we say that user agent would ask permission each time then it would be very strange behaviour.

Bryan: the intent is not to over-prompt the user for permission.

Eduardo: I think the different registrations can be differentiated with the push registration ID.
... this is unique to the each registration.
... notifications associated to each registration are differentiated by ID.

Bryan: then a number of suggestions for renaming. In general they are OK.

Eduardo: no it would't be a problem to change the naming.

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.
... 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.
... hopefully in my email response this is clarified.
... I think it would be great to have concrete examples and I can provide those for the ones I'm familiar with.

Tim: it can't be used in any context

Bryan: it probably does;t have any meaning in any other context.
... 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.
... we might have some new specs come out on these if we can people can bring that to the table.
... next question - related to the idea of a message queue.
... why not use DOM event model?

Eduardo: this is based on the system messages design.
... seems system messages are going to be discontinued. So we need to find an altertnative.

Bryan: I agree we should use tired and true eventing interfaces.
... final question - it's unclear from the code examples how this is meant to be invoked.
... it's largely left out of scope.
... the system being the push server and the user agent are assumed to know about eachother.
... that might in the end rely on service workers.
... but it's considered to be out of scope.

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

Bryan: that is one of the permutations we are going to haver to cover.

Peter: anything else?

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.

I suggest we add this to our f2f agenda and maybe we can ask Eduardo and Bryan to call in?

Peter: thanks all for joining us.
... we need to keep lines of communication open.
... we have a f2f coming up in a couple weeks.

Jan 7-9

Eduardo: yes it's ok.

Bryan: i'l be at CES but I'll do my best.

Peter: Tim did you want to bring up http 209?

HTTP Code 209

tim: something the tag talked about way back. Linked to http-range-14.
... this shouldn't involve too much philosophy.
... 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.
... in LD it happens when X is some abstract thing and Y is a document about the thing.
... the time it would be useful - you've asked for a database but I'm going to give you info for querying it.
... 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.
... 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.
... all this happens with a 303. 303s involve a http roundtrip. slows things down.
... so the conclusion is - having another 20x code - a 209. this is equivalent of a 303 followed by a 200.
... this will speed things up a lot.
... reason I'm bringing to the TAG - the LDP working group needs this ... but could be useful to anyone using 303.
... [hasn't happened becasuse] defining a new return code would be trouble... we'll have to make an RFC...
... I feel it would be good for the web to have a new 20x code ...
... [has been some disconnect between LD people / semantic web people / protocol people ]
... so what should we do? One possibility is for LDP to ask Yves nicely to do this - as an RFC>
... and get this adopted.
... or maybe we should get write an extension spec.

<Yves> http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

tim: one possiblity is to do ths...

Yves: first the http status code registry requires IETF consensus - so you need an rfc.

Tim: does it have a way of reserving a code?

Yves: no.

Yves. Non.

Yves: ...but chances are high that if you have a draft out there then it won't be taken.

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

Yves: the best is to have the group interested in working on that draft (as an RFC) what they want to have.
... then get feedback from IETF community.

Peter: should we discuss during the data on the web topic at the f2f.

Tim: yes I'm happy with that.

Dan: could be useful to have some draft text as a straw man.

Tim: yes - it sounds like a small thing but ...
... something like 233 or somehting....

<Yves> example of a small rfc to add a status code: http://tools.ietf.org/html/draft-reschke-http-status-308-07

One question I have: does it have non-data non-LD use cases?

Tim: what's interesting about is the machine understanding the relationship between the two documents.
... if you're dealing with a human being you just get a 200.

Dan: would it be useful in a httprequest context?

Tim: it would be more useful in machine-readable context.
... it would only work if you had an expect ion fron the server that the clinet would understand it .

Peter: you also mentioned a case using it for pagination.
... that could have broader use for API calls as well...

Tim: another use - [in captive portals]
... I think the 209 is a simple thing to push through.

[discussion / rant on captive portals and the evil of...]

Adjourned

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-12-20 16:18:00 $