See also: IRC log
<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
<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?
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