RE: Push API draft uploaded
Greetings Bryan, First thanks for digging into it, here are some comments I have mostly stuff I feel is missing from the spec (and I guess some points may be open to discussion on wether they fall in the scope of this spec or not) : - Positioning towards the eventSource API. As far as developer is concerned both these specs seem to accomplish mostly the same thing. I feel we should add some clarification on when one or the other should be used. - Some callflows (I guess this is due to the early stage of the spec tho), from what I get the UA creates a pushservice indicating the URL of a selected push proxy and gets a URL where the webapp can send messages to that it then needs to communicate to the service server to actually be able to start getting messages. - Specs for the proxy, so far only the user agent side is defined and the exchanges between UA and proxy seem to remain fuzzy, same goes on the exchanges between proxy and web server. - Bearer switching, one of the points to introduce the spec was to be able to switch bearers for eventsources to allow battery saving on mobile devices. But there seems to be nothing about it in the spec. Are we letting the bearer switch to be done by the use of a different push service for lets say IP and SMS Push ? If so how is the change handled and what events can the app developer rely on to decide to switch ? - SLAs, default services, multiple services... Again from a first look every application seems to be able to select its own push service proxy, as it is defined I feel the application developer has to publish his own push proxy in order to use the API (that's why I feel we should have a must have for a default proxy somewhere (could actually just be some kind of fallback to eventsource). Also every application can have its own proxy, if those proxies are some of those proxies are public (ie accept notification support from other applications) it would be interesting to know that and also to know if some of those proxies offer some guarantees as far as QoS is concerned, and thus have some form of mechanism to discover registered proxys within the browser (doubt the intent mechanism is ideal for this however) and criterias to select which one my application can use. Cheers, Arnaud Braud _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you.
RE: Push API draft uploaded
Comment inline. Thanks, Bryan Sullivan -Original Message- From: Tobie Langel [mailto:to...@fb.com] Sent: Tuesday, June 05, 2012 12:28 PM To: Mounir Lamouri; public-webapps@w3.org Subject: Re: Push API draft uploaded On 6/5/12 4:00 PM, Mounir Lamouri mou...@lamouri.fr wrote: On 05/31/2012 03:28 PM, Tobie Langel wrote: I'm probably missing something here, but notifications don't seem to be going through a system- / browser-wide notification panel from which the user can decide whether or not to navigate to an application. In other words, it looks like we're considering server -- app push notifications, rather than server -- user push notifications. If that's case, how are we planning to handle waking up application A without disrupting the experience of the user currently busy using application B in the foreground (thinking essentially of mobile here)? Are we going to wake up application B but run it as a background app? If so, where is that behavior defined? Is that akin to a WebWorker or more of a headless window? What's the life-cycle of such an app? Also, how can this app alert the user that it has something new for him? Do we also have system level notifications in the work? If a given notification's sole purpose is to advise the user of some information he may or not want to act upon (e.g.: you have new mail), what are the benefits of waking up the application (or even spawning a worker) to do so? That seems like it would drain the battery of mobile devices for little purpose. Finally, aren't we conflating the notion of background work following a remote server or system event with that of push notification to the user? An example of background work following a remote server event would be the background update of daily news for a newspaper application. A remote server would send an event to the system / browser which itself would launch a WebWorker, that worker would perform the necessary io to upload the fresh content and save it in a db. An example of background work following a system event would be a location change event spawning a background worker which itself either stored the coordinates in a db or sent them to a remote server, e.g. for a cycling app tracking your rides. Example of push notifications for the user are things like You've got a new message, It's Emma's birthday today, etc. The user can decide to act upon them (i.e. follow the provided link) or not, but until he does, there's no reason to launch an app or even a worker. Note that similar notifications would also need to be issued by background workers / windows. E.g. The worker spawned above to upload fresh content for the newspaper app would be able to send a notification to the user when it's done (e.g. Today's news are been downloaded.) Sorry if the above feels a bit like a brain dump. I'm really struggling to understand the scope of this proposal. :-/ Actually, our System Message API [1] seems to answer most of those questions: an application will be able to specify a worker or a page to use when handling a message so it will be able to just run stuff in the background and depending on what happened do something like show a notification (via Desktop Notifications) or update a DB, or whatever. [1] https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3 c6e4c31d04b663/ Thanks for the link! While it's possible to display push notifications to the user via this proposal (push notification spawns a worker which notifies the user via Desktop Notification), on mobile it's probably a quantifiable waste of battery life compared to push notifications that are directly aimed at the user. For applications built in a more traditional way (with server side rendering, etc.), it still feels like providing the data in query params should be investigated before it's dismissed. Overall, I feel like writing down use cases and requirements would be something useful to do at this point. What do you think? bryan Here is the thread for the set of use cases I submitted for this API during the rechartering: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html. Additional use cases are welcome, and we can capture them and derived requirements on the Webapps wiki. I created a page for this: http://www.w3.org/2008/webapps/wiki/Push_API --tobie
Re: Push API draft uploaded
On 6/6/12 6:05 PM, SULLIVAN, BRYAN L bs3...@att.com wrote: Here is the thread for the set of use cases I submitted for this API during the rechartering: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html. Additional use cases are welcome, and we can capture them and derived requirements on the Webapps wiki. I created a page for this: http://www.w3.org/2008/webapps/wiki/Push_API Thanks for the links, Bryan. Will add use cases. --tobie
Re: Push API draft uploaded
On 05/31/2012 03:28 PM, Tobie Langel wrote: I'm probably missing something here, but notifications don't seem to be going through a system- / browser-wide notification panel from which the user can decide whether or not to navigate to an application. In other words, it looks like we're considering server -- app push notifications, rather than server -- user push notifications. If that's case, how are we planning to handle waking up application A without disrupting the experience of the user currently busy using application B in the foreground (thinking essentially of mobile here)? Are we going to wake up application B but run it as a background app? If so, where is that behavior defined? Is that akin to a WebWorker or more of a headless window? What's the life-cycle of such an app? Also, how can this app alert the user that it has something new for him? Do we also have system level notifications in the work? If a given notification's sole purpose is to advise the user of some information he may or not want to act upon (e.g.: you have new mail), what are the benefits of waking up the application (or even spawning a worker) to do so? That seems like it would drain the battery of mobile devices for little purpose. Finally, aren't we conflating the notion of background work following a remote server or system event with that of push notification to the user? An example of background work following a remote server event would be the background update of daily news for a newspaper application. A remote server would send an event to the system / browser which itself would launch a WebWorker, that worker would perform the necessary io to upload the fresh content and save it in a db. An example of background work following a system event would be a location change event spawning a background worker which itself either stored the coordinates in a db or sent them to a remote server, e.g. for a cycling app tracking your rides. Example of push notifications for the user are things like You've got a new message, It's Emma's birthday today, etc. The user can decide to act upon them (i.e. follow the provided link) or not, but until he does, there's no reason to launch an app or even a worker. Note that similar notifications would also need to be issued by background workers / windows. E.g. The worker spawned above to upload fresh content for the newspaper app would be able to send a notification to the user when it's done (e.g. Today's news are been downloaded.) Sorry if the above feels a bit like a brain dump. I'm really struggling to understand the scope of this proposal. :-/ Actually, our System Message API [1] seems to answer most of those questions: an application will be able to specify a worker or a page to use when handling a message so it will be able to just run stuff in the background and depending on what happened do something like show a notification (via Desktop Notifications) or update a DB, or whatever. [1] https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3c6e4c31d04b663/ Cheers, -- Mounir
Re: Push API draft uploaded
On 6/5/12 4:00 PM, Mounir Lamouri mou...@lamouri.fr wrote: On 05/31/2012 03:28 PM, Tobie Langel wrote: I'm probably missing something here, but notifications don't seem to be going through a system- / browser-wide notification panel from which the user can decide whether or not to navigate to an application. In other words, it looks like we're considering server -- app push notifications, rather than server -- user push notifications. If that's case, how are we planning to handle waking up application A without disrupting the experience of the user currently busy using application B in the foreground (thinking essentially of mobile here)? Are we going to wake up application B but run it as a background app? If so, where is that behavior defined? Is that akin to a WebWorker or more of a headless window? What's the life-cycle of such an app? Also, how can this app alert the user that it has something new for him? Do we also have system level notifications in the work? If a given notification's sole purpose is to advise the user of some information he may or not want to act upon (e.g.: you have new mail), what are the benefits of waking up the application (or even spawning a worker) to do so? That seems like it would drain the battery of mobile devices for little purpose. Finally, aren't we conflating the notion of background work following a remote server or system event with that of push notification to the user? An example of background work following a remote server event would be the background update of daily news for a newspaper application. A remote server would send an event to the system / browser which itself would launch a WebWorker, that worker would perform the necessary io to upload the fresh content and save it in a db. An example of background work following a system event would be a location change event spawning a background worker which itself either stored the coordinates in a db or sent them to a remote server, e.g. for a cycling app tracking your rides. Example of push notifications for the user are things like You've got a new message, It's Emma's birthday today, etc. The user can decide to act upon them (i.e. follow the provided link) or not, but until he does, there's no reason to launch an app or even a worker. Note that similar notifications would also need to be issued by background workers / windows. E.g. The worker spawned above to upload fresh content for the newspaper app would be able to send a notification to the user when it's done (e.g. Today's news are been downloaded.) Sorry if the above feels a bit like a brain dump. I'm really struggling to understand the scope of this proposal. :-/ Actually, our System Message API [1] seems to answer most of those questions: an application will be able to specify a worker or a page to use when handling a message so it will be able to just run stuff in the background and depending on what happened do something like show a notification (via Desktop Notifications) or update a DB, or whatever. [1] https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3 c6e4c31d04b663/ Thanks for the link! While it's possible to display push notifications to the user via this proposal (push notification spawns a worker which notifies the user via Desktop Notification), on mobile it's probably a quantifiable waste of battery life compared to push notifications that are directly aimed at the user. For applications built in a more traditional way (with server side rendering, etc.), it still feels like providing the data in query params should be investigated before it's dismissed. Overall, I feel like writing down use cases and requirements would be something useful to do at this point. What do you think? --tobie
RE: Push API draft uploaded
Responses inline. Thanks, Bryan Sullivan -Original Message- From: Tobie Langel [mailto:to...@fb.com] Sent: Thursday, May 31, 2012 6:29 AM To: public-webapps@w3.org Subject: Re: Push API draft uploaded On 5/30/12 11:14 AM, Mounir Lamouri mou...@lamouri.fr wrote: * I guess the idea of |onmessage| is that the PushService instance will get an event when the backend will push a notification to the webapp. However, I wonder how you do handle the situation when the application is actually not being ran. Or should we wait for it to be launched? Anyhow, coupling the URL request and the event handling at the same place seems weird. bryan Not at all. This is the way that EventSource works for example (the message handler is overtly associated with the request to a specific service URL). I'm not sure what you mean by when the application is actually not being ran... if you mean when the app is not running, the answer is yes, the app should be started and the event then delivered to it. Running a webapp/website then sending an event to it seems a rather hard task. This is actually what motivated the System Message Handler API. bryan I'm not sure how it's hard; the Webapp just arranges for Push message delivery when it is invoked, and events are delivered to the object that represents the service arrangement (whether connection-based or connectionless or whatever). I may be missing your counterpoint. I wasn't clear I think. If you start an application because of a particular event, the application has no way to know it has been started because of the event until the event is actually sent. But the event will be sent at a point during load (or after) and in the meantime, the application might show a UI as if it was simply started by the user. So you might have a weird UI flickering where something will be shown and very quickly will be changed to something else because of the push notification coming. Agreed with Mounir here. While passing an event to a running app makes sense (and already exists in the form of EventSource) it really doesn't for apps which are not running. Passing the event data as query params seems more suitable in that case. bryan If the event data can be passed through a fragment (e.g. there are no major limitations on that approach), and easily discovered/accessed by the app, then that would be a good approach. Can you provide an example of how that would work? * If we want want a |wakeup| attribute, this might need to live in the manifest as Jose suggested. In general, I wonder if that should be something the UA requests. I would understand why the UA would ignore |wakeup = true| but I wouldn't understand why it should always follows the passed value. bryan The wakeup feature might be turned on by the app through an interface with the user, and used sometimes and others not per the needs of the app and preferences of the user (app managed). If it's in the manifest, it's fixed. I don't believe the UA should ignore the requirements of the app, when the user has given their permission for its operation as needed (both by browsing/installing the app, and overtly by approving Push service use). I'm not sure I understand how the user would give its permission here. bryan By navigating to the Webapp (implicitly, in the case that the Webapp had previously been permitted access to Push services by the user), and by accepting the UA's prompt as to whether this app should be allowed to receive Push messages the first time the user navigates to it (explicitly). So the user doesn't really give its permission to the app to wakeup the device but to the app to be able to receive push notifications. Then, the app is the only one deciding if it will wakeup the device or not. I'm not a big fan of that approach but I don't really have a better idea for the moment. I'm probably missing something here, but notifications don't seem to be going through a system- / browser-wide notification panel from which the user can decide whether or not to navigate to an application. In other words, it looks like we're considering server -- app push notifications, rather than server -- user push notifications. bryan Correct, the objective is application messaging, not user messaging. Like other aspects of the UX e.g. that supported by the Web since AJAX became popular, we don't think it's necessary or effective to require the user to be involved in all client-server interactions. If that's case, how are we planning to handle waking up application A without disrupting the experience of the user currently busy using application B in the foreground (thinking essentially of mobile here)? bryan Apps that can be automatically woken up would benefit from need enabling cooperative design that results in a good UX, e.g. the ability to be invoked and startup in the background, if there is another foreground app (whether in the Web runtime or a native app), and inform the user through
Re: Push API draft uploaded
On 5/30/12 11:14 AM, Mounir Lamouri mou...@lamouri.fr wrote: * I guess the idea of |onmessage| is that the PushService instance will get an event when the backend will push a notification to the webapp. However, I wonder how you do handle the situation when the application is actually not being ran. Or should we wait for it to be launched? Anyhow, coupling the URL request and the event handling at the same place seems weird. bryan Not at all. This is the way that EventSource works for example (the message handler is overtly associated with the request to a specific service URL). I'm not sure what you mean by when the application is actually not being ran... if you mean when the app is not running, the answer is yes, the app should be started and the event then delivered to it. Running a webapp/website then sending an event to it seems a rather hard task. This is actually what motivated the System Message Handler API. bryan I'm not sure how it's hard; the Webapp just arranges for Push message delivery when it is invoked, and events are delivered to the object that represents the service arrangement (whether connection-based or connectionless or whatever). I may be missing your counterpoint. I wasn't clear I think. If you start an application because of a particular event, the application has no way to know it has been started because of the event until the event is actually sent. But the event will be sent at a point during load (or after) and in the meantime, the application might show a UI as if it was simply started by the user. So you might have a weird UI flickering where something will be shown and very quickly will be changed to something else because of the push notification coming. Agreed with Mounir here. While passing an event to a running app makes sense (and already exists in the form of EventSource) it really doesn't for apps which are not running. Passing the event data as query params seems more suitable in that case. * If we want want a |wakeup| attribute, this might need to live in the manifest as Jose suggested. In general, I wonder if that should be something the UA requests. I would understand why the UA would ignore |wakeup = true| but I wouldn't understand why it should always follows the passed value. bryan The wakeup feature might be turned on by the app through an interface with the user, and used sometimes and others not per the needs of the app and preferences of the user (app managed). If it's in the manifest, it's fixed. I don't believe the UA should ignore the requirements of the app, when the user has given their permission for its operation as needed (both by browsing/installing the app, and overtly by approving Push service use). I'm not sure I understand how the user would give its permission here. bryan By navigating to the Webapp (implicitly, in the case that the Webapp had previously been permitted access to Push services by the user), and by accepting the UA's prompt as to whether this app should be allowed to receive Push messages the first time the user navigates to it (explicitly). So the user doesn't really give its permission to the app to wakeup the device but to the app to be able to receive push notifications. Then, the app is the only one deciding if it will wakeup the device or not. I'm not a big fan of that approach but I don't really have a better idea for the moment. I'm probably missing something here, but notifications don't seem to be going through a system- / browser-wide notification panel from which the user can decide whether or not to navigate to an application. In other words, it looks like we're considering server -- app push notifications, rather than server -- user push notifications. If that's case, how are we planning to handle waking up application A without disrupting the experience of the user currently busy using application B in the foreground (thinking essentially of mobile here)? Are we going to wake up application B but run it as a background app? If so, where is that behavior defined? Is that akin to a WebWorker or more of a headless window? What's the life-cycle of such an app? Also, how can this app alert the user that it has something new for him? Do we also have system level notifications in the work? If a given notification's sole purpose is to advise the user of some information he may or not want to act upon (e.g.: you have new mail), what are the benefits of waking up the application (or even spawning a worker) to do so? That seems like it would drain the battery of mobile devices for little purpose. Finally, aren't we conflating the notion of background work following a remote server or system event with that of push notification to the user? An example of background work following a remote server event would be the background update of daily news for a newspaper application. A remote server would send an event to the system / browser which itself would launch a WebWorker, that worker
RE: Push API draft uploaded
Responses inline. Thanks, Bryan Sullivan -Original Message- From: Mounir Lamouri [mailto:mou...@lamouri.fr] Sent: Wednesday, May 30, 2012 2:15 AM To: public-webapps@w3.org Subject: Re: Push API draft uploaded On 05/29/2012 06:13 PM, SULLIVAN, BRYAN L wrote: * I wonder if it is really useful to have clients requesting a specific Push service. I totally understand why a user would request to use his preferred Push service but that is part of the UA. I would tend to think we should not add that parameter until it's proven to be needed by some consumer of the API. Adding it would be simple; removing it might not be an option. Also, allowing a website to chose the Push service might break the entire idea of decentralization here: you might end up with most websites requesting to use push.popularservice.com. bryan If a service is effective and thus popular, why shouldn't it be accessible to developers? Rather than break decentralization, this flexibility enables it IMO, so I think there is a misunderstanding somewhere. To enable some degree of Push service (and thus service provider) flexibility, I have also proposed that we could use Web Intents as a way to allow the user to select the service provider, but if the app has particular requirements (e.g. security or delivery methods/bearers), I see no reason why we should obfuscate the developer intent by making the user play the match maker. The requested service URL also provides means to negotiate additional functionality/options between the app and the Push service directly e.g. as above (e.g. security, delivery methods/bearers, application characteristics, ...). I don't how this could be related to Web Intents? Picking the service provider should be up to the UA (using whichever method the UA feels appropriate). If a website *needs* a specific service provider that means this API has been a failure so I wouldn't add a parameter that would help this happen. bryan The concept of service provider selection by the user (in essence the provider of some functionality distributed as Web pages/applications/workers etc) is fundamental to the Web Intents concept, so it seemed natural to me to consider that for this API. I don't think UA's should be exclusively responsible for service provider selection, for this purpose or others. If service providers can be more flexibly integrated through APIs such as Web Intents IMO that is good for the Web. I do not understand why a concept should be used in this specification because it is used in Web Intents. And I do not understand why making an API integrated with Web Intents is good for the Web. Really bryan The concept of a requested service URL is not in this spec because the concept is used in or borrowed from Web Intents. The concept is there because it allows developers the flexibility of Push service provider selection. On its own, it has no dependency upon Web Intents. I mention Web Intents only to illustrate that as an additional potential mechanism, it can be considered as a specific way to get the user involved in the Push service provider selection, if the developer has no preference in the matter. * |readyState| should be a DOMString. bryan The jury is out on this, AFAICT. It's a short in EventSource and XHR. I was following their lead. I don't know for XHR but the new way is DOMString for multiple reasons. I believe Ms2ger pointed you to a link which likely explains those. bryan If we can get Webapps resolution on that as a recommended design approach going forward, as I said I am open to this. Perhaps the XHR and EventSource editors can voice an opinion here? XHR just can't be changed, this is why it is keeping integers instead of string for errors. I do not know for EventSource. Anyhow, I'm not going to argue more on that subject. * I guess the idea of |onmessage| is that the PushService instance will get an event when the backend will push a notification to the webapp. However, I wonder how you do handle the situation when the application is actually not being ran. Or should we wait for it to be launched? Anyhow, coupling the URL request and the event handling at the same place seems weird. bryan Not at all. This is the way that EventSource works for example (the message handler is overtly associated with the request to a specific service URL). I'm not sure what you mean by when the application is actually not being ran... if you mean when the app is not running, the answer is yes, the app should be started and the event then delivered to it. Running a webapp/website then sending an event to it seems a rather hard task. This is actually what motivated the System Message Handler API. bryan I'm not sure how it's hard; the Webapp just arranges for Push message delivery when it is invoked, and events are delivered to the object that represents the service arrangement (whether connection-based
Re: Push API draft uploaded
On 05/29/2012 06:13 PM, SULLIVAN, BRYAN L wrote: * I wonder if it is really useful to have clients requesting a specific Push service. I totally understand why a user would request to use his preferred Push service but that is part of the UA. I would tend to think we should not add that parameter until it's proven to be needed by some consumer of the API. Adding it would be simple; removing it might not be an option. Also, allowing a website to chose the Push service might break the entire idea of decentralization here: you might end up with most websites requesting to use push.popularservice.com. bryan If a service is effective and thus popular, why shouldn't it be accessible to developers? Rather than break decentralization, this flexibility enables it IMO, so I think there is a misunderstanding somewhere. To enable some degree of Push service (and thus service provider) flexibility, I have also proposed that we could use Web Intents as a way to allow the user to select the service provider, but if the app has particular requirements (e.g. security or delivery methods/bearers), I see no reason why we should obfuscate the developer intent by making the user play the match maker. The requested service URL also provides means to negotiate additional functionality/options between the app and the Push service directly e.g. as above (e.g. security, delivery methods/bearers, application characteristics, ...). I don't how this could be related to Web Intents? Picking the service provider should be up to the UA (using whichever method the UA feels appropriate). If a website *needs* a specific service provider that means this API has been a failure so I wouldn't add a parameter that would help this happen. bryan The concept of service provider selection by the user (in essence the provider of some functionality distributed as Web pages/applications/workers etc) is fundamental to the Web Intents concept, so it seemed natural to me to consider that for this API. I don't think UA's should be exclusively responsible for service provider selection, for this purpose or others. If service providers can be more flexibly integrated through APIs such as Web Intents IMO that is good for the Web. I do not understand why a concept should be used in this specification because it is used in Web Intents. And I do not understand why making an API integrated with Web Intents is good for the Web. Really. * |readyState| should be a DOMString. bryan The jury is out on this, AFAICT. It's a short in EventSource and XHR. I was following their lead. I don't know for XHR but the new way is DOMString for multiple reasons. I believe Ms2ger pointed you to a link which likely explains those. bryan If we can get Webapps resolution on that as a recommended design approach going forward, as I said I am open to this. Perhaps the XHR and EventSource editors can voice an opinion here? XHR just can't be changed, this is why it is keeping integers instead of string for errors. I do not know for EventSource. Anyhow, I'm not going to argue more on that subject. * I guess the idea of |onmessage| is that the PushService instance will get an event when the backend will push a notification to the webapp. However, I wonder how you do handle the situation when the application is actually not being ran. Or should we wait for it to be launched? Anyhow, coupling the URL request and the event handling at the same place seems weird. bryan Not at all. This is the way that EventSource works for example (the message handler is overtly associated with the request to a specific service URL). I'm not sure what you mean by when the application is actually not being ran... if you mean when the app is not running, the answer is yes, the app should be started and the event then delivered to it. Running a webapp/website then sending an event to it seems a rather hard task. This is actually what motivated the System Message Handler API. bryan I'm not sure how it's hard; the Webapp just arranges for Push message delivery when it is invoked, and events are delivered to the object that represents the service arrangement (whether connection-based or connectionless or whatever). I may be missing your counterpoint. I wasn't clear I think. If you start an application because of a particular event, the application has no way to know it has been started because of the event until the event is actually sent. But the event will be sent at a point during load (or after) and in the meantime, the application might show a UI as if it was simply started by the user. So you might have a weird UI flickering where something will be shown and very quickly will be changed to something else because of the push notification coming. * If we want want a |wakeup| attribute, this might need to live in the manifest as Jose suggested. In general, I wonder if that should be something the UA
Re: Push API draft uploaded
On 05/26/2012 05:06 AM, SULLIVAN, BRYAN L wrote: * As far as I understand it, |requestRemotePermission| and |checkRemotePermission| could be one single method which could be named something like |getPushServiceUrl|. The only difference between those two methods is the permission asking part but that should stay as a UA decision. Given that the method is anyway asynchronous, the UA can do whatever wanted before sending a result. Showing a permission prompt could be one of those. bryan I agree that these methods could collapse into one. But as this interface was based upon the Mozilla proposal (https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to get the author's view on the potential to collapse the two methods into one. I wouldn't name the proposal on the wiki page as Mozilla's proposal. This wiki is public and what is described is far from being a finished work. In addition, the wiki page is quite explicit about the existence of those two methods and the given reasons are quite invalid. * I wonder if it is really useful to have clients requesting a specific Push service. I totally understand why a user would request to use his preferred Push service but that is part of the UA. I would tend to think we should not add that parameter until it's proven to be needed by some consumer of the API. Adding it would be simple; removing it might not be an option. Also, allowing a website to chose the Push service might break the entire idea of decentralization here: you might end up with most websites requesting to use push.popularservice.com. bryan If a service is effective and thus popular, why shouldn't it be accessible to developers? Rather than break decentralization, this flexibility enables it IMO, so I think there is a misunderstanding somewhere. To enable some degree of Push service (and thus service provider) flexibility, I have also proposed that we could use Web Intents as a way to allow the user to select the service provider, but if the app has particular requirements (e.g. security or delivery methods/bearers), I see no reason why we should obfuscate the developer intent by making the user play the match maker. The requested service URL also provides means to negotiate additional functionality/options between the app and the Push service directly e.g. as above (e.g. security, delivery methods/bearers, application characteristics, ...). I don't how this could be related to Web Intents? Picking the service provider should be up to the UA (using whichever method the UA feels appropriate). If a website *needs* a specific service provider that means this API has been a failure so I wouldn't add a parameter that would help this happen. * I'm not sure why you have a |requestUrl| attribute in PushService. Do you have any use case for that? bryan The use case is that an app can have multiple Push service requests active at a time, with different URLs. In order to be able to associate each PushService object with a specific set of options or services for example, it needs to know what URL was used when the PushService object was created. The intent is similar to that of EventSource, which has the url attribute for a similar purpose (at least that is how I have used it). And since the checkRemotePermission() method needs to verify the permission for the same URL, it is better to have the resolved form of the URL available as an attribute, so that it's easy to call the checkRemotePermission() method for the right URL (as the absolute URL may have changed since the original resolution). The resolving part seems quite useless because contrary to EventSource, it might be pretty uncommon to use a relative path to the push service. Anyhow, I think this should disappear with the parameter in the methods. The client shouldn't know which server is used: this is part of the user's privacy. * |readyState| should be a DOMString. bryan The jury is out on this, AFAICT. It's a short in EventSource and XHR. I was following their lead. I don't know for XHR but the new way is DOMString for multiple reasons. I believe Ms2ger pointed you to a link which likely explains those. * I guess the idea of |onmessage| is that the PushService instance will get an event when the backend will push a notification to the webapp. However, I wonder how you do handle the situation when the application is actually not being ran. Or should we wait for it to be launched? Anyhow, coupling the URL request and the event handling at the same place seems weird. bryan Not at all. This is the way that EventSource works for example (the message handler is overtly associated with the request to a specific service URL). I'm not sure what you mean by when the application is actually not being ran... if you mean when the app is not running, the answer is yes, the app should be started and the event then delivered to it. Running a
RE: Push API draft uploaded
No, the proposal at https://wiki.mozilla.org/Services/Notifications/Push/API. This was mentioned by Jonas at the Webapps meeting as the way that Mozilla is looking at this API. In that API there are two methods: requestRemotePermission() and checkRemotePermission(); But also separately, I am considering how Web Intents can be used for API service provider discovery, and use. Thanks, Bryan Sullivan -Original Message- From: Mounir Lamouri [mailto:mou...@lamouri.fr] Sent: Tuesday, May 29, 2012 2:48 AM To: public-webapps@w3.org Subject: Re: Push API draft uploaded On 05/25/2012 04:00 PM, SULLIVAN, BRYAN L wrote: [...] I am following the Mozilla lead on registering the intent to receive messages, [...]. I'm not sure I understand. Do you mean the proposal on the wiki page is proposing to use intents? -- Mounir
RE: Push API draft uploaded
Responses inline. Thanks, Bryan Sullivan -Original Message- From: Mounir Lamouri [mailto:mou...@lamouri.fr] Sent: Tuesday, May 29, 2012 3:06 AM To: public-webapps@w3.org Subject: Re: Push API draft uploaded On 05/26/2012 05:06 AM, SULLIVAN, BRYAN L wrote: * As far as I understand it, |requestRemotePermission| and |checkRemotePermission| could be one single method which could be named something like |getPushServiceUrl|. The only difference between those two methods is the permission asking part but that should stay as a UA decision. Given that the method is anyway asynchronous, the UA can do whatever wanted before sending a result. Showing a permission prompt could be one of those. bryan I agree that these methods could collapse into one. But as this interface was based upon the Mozilla proposal (https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to get the author's view on the potential to collapse the two methods into one. I wouldn't name the proposal on the wiki page as Mozilla's proposal. This wiki is public and what is described is far from being a finished work. In addition, the wiki page is quite explicit about the existence of those two methods and the given reasons are quite invalid. bryan OK, I am open to collapsing these two methods into one, and will update the draft with a proposal for that. * I wonder if it is really useful to have clients requesting a specific Push service. I totally understand why a user would request to use his preferred Push service but that is part of the UA. I would tend to think we should not add that parameter until it's proven to be needed by some consumer of the API. Adding it would be simple; removing it might not be an option. Also, allowing a website to chose the Push service might break the entire idea of decentralization here: you might end up with most websites requesting to use push.popularservice.com. bryan If a service is effective and thus popular, why shouldn't it be accessible to developers? Rather than break decentralization, this flexibility enables it IMO, so I think there is a misunderstanding somewhere. To enable some degree of Push service (and thus service provider) flexibility, I have also proposed that we could use Web Intents as a way to allow the user to select the service provider, but if the app has particular requirements (e.g. security or delivery methods/bearers), I see no reason why we should obfuscate the developer intent by making the user play the match maker. The requested service URL also provides means to negotiate additional functionality/options between the app and the Push service directly e.g. as above (e.g. security, delivery methods/bearers, application characteristics, ...). I don't how this could be related to Web Intents? Picking the service provider should be up to the UA (using whichever method the UA feels appropriate). If a website *needs* a specific service provider that means this API has been a failure so I wouldn't add a parameter that would help this happen. bryan The concept of service provider selection by the user (in essence the provider of some functionality distributed as Web pages/applications/workers etc) is fundamental to the Web Intents concept, so it seemed natural to me to consider that for this API. I don't think UA's should be exclusively responsible for service provider selection, for this purpose or others. If service providers can be more flexibly integrated through APIs such as Web Intents IMO that is good for the Web. * I'm not sure why you have a |requestUrl| attribute in PushService. Do you have any use case for that? bryan The use case is that an app can have multiple Push service requests active at a time, with different URLs. In order to be able to associate each PushService object with a specific set of options or services for example, it needs to know what URL was used when the PushService object was created. The intent is similar to that of EventSource, which has the url attribute for a similar purpose (at least that is how I have used it). And since the checkRemotePermission() method needs to verify the permission for the same URL, it is better to have the resolved form of the URL available as an attribute, so that it's easy to call the checkRemotePermission() method for the right URL (as the absolute URL may have changed since the original resolution). The resolving part seems quite useless because contrary to EventSource, it might be pretty uncommon to use a relative path to the push service. Anyhow, I think this should disappear with the parameter in the methods. The client shouldn't know which server is used: this is part of the user's privacy. bryan But as with EventSource, we won't know if the service URL will be commonly relative, or not. EventSource itself is quite young in terms of adoption, and with CORS there are good reasons why the path *won't
Re: Push API draft uploaded
I have some comments: I think the idea is to decouple permissions from APIs, making that part of a Security Model, so I don't understand why we are putting here that functionality. Concerning wakeup, etc. I think that should not be part of the API itself but of the App Manifest I think we need to distinguish between registering the interest on receiving push messages and receiving push messages themselves. The current API does not address the possibility of having a queue of pending messages. best El 24/05/12 09:14, SULLIVAN, BRYAN L bs3...@att.com escribió: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html I incorporated Mozilla's client API ideas in https://wiki.mozilla.org/Services/Notifications/Push/API as the PushManager interface, and also in the PushService interface with some additions to support a more explicit event model for received message delivery, derived from Server-Sent Events. A lot is still left unsaid, and I will work on examples. I also have not addressed the server API aspect that Mozilla mentioned in their proposal. Like a lot that is left unsaid in their client API proposal (how does the browser determine what that magic server URL is...?), the server API is likely related to the specific Push service that is bound to the API. I am considering the use of Web Intents to discover and select the Push Service provider that the user wants apps to use, assuming that we can leave the backend details to the intent provider. I'm not yet sure how the pieces will fit together, how much needs to be defined, and how my earlier proposal about specific event source selection and filtering fits into this, but it's a start. Thanks, Bryan Sullivan Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx
RE: Push API draft uploaded
Hi Jose, Thanks for the comments. Re the idea is to decouple permissions from APIs: potentially for the Sysapps WG this will be possible, but currently in DAP and in Webapps if the Web security model isn't enough (e.g. same-origin and CORS), then any special considerations are addressed in the API specs themselves. In this case the ability to invoke the app (wakeup) and receive Push messages when the app is offline in general (as in the Mozilla proposal) goes beyond the ability of same-origin and CORS to ensure user protection. Thus the user is prompted at least once. It's not a perfect solution but at least consistent with what has been the approach, and usable until we get to a more robust permissions framework. Re wakeup as part of an App Manifest: this does not yet apply to Web apps in general. It does seem useful to consider in the Web app manifest (https://people.mozilla.com/~anarayanan/webapps.html) as proposed to be worked in Webapps, but again that does not apply (or does not have to be used) for all Web apps. I suppose one could make the argument that if you expect to be woken up, the app should be installed, but I think caching also works for that (as described in the spec as Examples of cases in which webapps should be invokable). Re distinguish between registering the interest on receiving push messages and receiving push messages themselves: I am following the Mozilla lead on registering the intent to receive messages, and also going beyond it with the actual reception capability, and there are separate interfaces for the two functions. We don't yet have a generic intent registration mechanism for use here (e.g. based upon the API feature URL concept previously proposed for Widgets and leveraged in WAC), and we may approach that again in Sysapps (TBD), but for now I think the APIs need to address both functions. Re the possibility of having a queue of pending messages: the spec leaves this as a MAY for now: When a Push message is received, the user agent must deliver the message data via the onmessage handler, if possible. If delivery is not possible, the user agent may discard the message, or may queue it for later delivery. Thanks, Bryan Sullivan -Original Message- From: JOSE MANUEL CANTERA FONSECA [mailto:j...@tid.es] Sent: Friday, May 25, 2012 4:36 AM To: SULLIVAN, BRYAN L; public-webapps Subject: Re: Push API draft uploaded I have some comments: I think the idea is to decouple permissions from APIs, making that part of a Security Model, so I don't understand why we are putting here that functionality. Concerning wakeup, etc. I think that should not be part of the API itself but of the App Manifest I think we need to distinguish between registering the interest on receiving push messages and receiving push messages themselves. The current API does not address the possibility of having a queue of pending messages. best El 24/05/12 09:14, SULLIVAN, BRYAN L bs3...@att.com escribió: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html I incorporated Mozilla's client API ideas in https://wiki.mozilla.org/Services/Notifications/Push/API as the PushManager interface, and also in the PushService interface with some additions to support a more explicit event model for received message delivery, derived from Server-Sent Events. A lot is still left unsaid, and I will work on examples. I also have not addressed the server API aspect that Mozilla mentioned in their proposal. Like a lot that is left unsaid in their client API proposal (how does the browser determine what that magic server URL is...?), the server API is likely related to the specific Push service that is bound to the API. I am considering the use of Web Intents to discover and select the Push Service provider that the user wants apps to use, assuming that we can leave the backend details to the intent provider. I'm not yet sure how the pieces will fit together, how much needs to be defined, and how my earlier proposal about specific event source selection and filtering fits into this, but it's a start. Thanks, Bryan Sullivan Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Re: Push API draft uploaded
On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html I incorporated Mozilla's client API ideas in https://wiki.mozilla.org/Serices/Notifications/Push/API as the PushManager interface, and also in the PushService interface with some additions to support a more explicit event model for received message delivery, derived from Server-Sent Events. A lot is still left unsaid, and I will work on examples. I also have not addressed the server API aspect that Mozilla mentioned in their proposal. Like a lot that is left unsaid in their client API proposal (how does the browser determine what that magic server URL is...?), the server API is likely related to the specific Push service that is bound to the API. I am considering the use of Web Intents to discover and select the Push Service provider that the user wants apps to use, assuming that we can leave the backend details to the intent provider. I'm not yet sure how the pieces will fit together, how much needs to be defined, and how my earlier proposal about specific event source selection and filtering fits into this, but it's a start. Hi, I have a few random comments: * As far as I understand it, |requestRemotePermission| and |checkRemotePermission| could be one single method which could be named something like |getPushServiceUrl|. The only difference between those two methods is the permission asking part but that should stay as a UA decision. Given that the method is anyway asynchronous, the UA can do whatever wanted before sending a result. Showing a permission prompt could be one of those. * I wonder if it is really useful to have clients requesting a specific Push service. I totally understand why a user would request to use his preferred Push service but that is part of the UA. I would tend to think we should not add that parameter until it's proven to be needed by some consumer of the API. Adding it would be simple; removing it might not be an option. Also, allowing a website to chose the Push service might break the entire idea of decentralization here: you might end up with most websites requesting to use push.popularservice.com. * I'm not sure why you have a |requestUrl| attribute in PushService. Do you have any use case for that? * |readyState| should be a DOMString. * I guess the idea of |onmessage| is that the PushService instance will get an event when the backend will push a notification to the webapp. However, I wonder how you do handle the situation when the application is actually not being ran. Or should we wait for it to be launched? Anyhow, coupling the URL request and the event handling at the same place seems weird. * If we want want a |wakeup| attribute, this might need to live in the manifest as Jose suggested. In general, I wonder if that should be something the UA requests. I would understand why the UA would ignore |wakeup = true| but I wouldn't understand why it should always follows the passed value. For the two last points, maybe using Mozilla's System Message Handler would help? See: https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3c6e4c31d04b663/ Cheers, -- Mounir
RE: Push API draft uploaded
Thanks for the comments. Some responses added as bryan Thanks, Bryan Sullivan -Original Message- From: Mounir Lamouri [mailto:mou...@lamouri.fr] Sent: Friday, May 25, 2012 3:17 PM To: public-webapps@w3.org Subject: Re: Push API draft uploaded On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html I incorporated Mozilla's client API ideas in https://wiki.mozilla.org/Serices/Notifications/Push/API as the PushManager interface, and also in the PushService interface with some additions to support a more explicit event model for received message delivery, derived from Server-Sent Events. A lot is still left unsaid, and I will work on examples. I also have not addressed the server API aspect that Mozilla mentioned in their proposal. Like a lot that is left unsaid in their client API proposal (how does the browser determine what that magic server URL is...?), the server API is likely related to the specific Push service that is bound to the API. I am considering the use of Web Intents to discover and select the Push Service provider that the user wants apps to use, assuming that we can leave the backend details to the intent provider. I'm not yet sure how the pieces will fit together, how much needs to be defined, and how my earlier proposal about specific event source selection and filtering fits into this, but it's a start. Hi, I have a few random comments: * As far as I understand it, |requestRemotePermission| and |checkRemotePermission| could be one single method which could be named something like |getPushServiceUrl|. The only difference between those two methods is the permission asking part but that should stay as a UA decision. Given that the method is anyway asynchronous, the UA can do whatever wanted before sending a result. Showing a permission prompt could be one of those. bryan I agree that these methods could collapse into one. But as this interface was based upon the Mozilla proposal (https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to get the author's view on the potential to collapse the two methods into one. * I wonder if it is really useful to have clients requesting a specific Push service. I totally understand why a user would request to use his preferred Push service but that is part of the UA. I would tend to think we should not add that parameter until it's proven to be needed by some consumer of the API. Adding it would be simple; removing it might not be an option. Also, allowing a website to chose the Push service might break the entire idea of decentralization here: you might end up with most websites requesting to use push.popularservice.com. bryan If a service is effective and thus popular, why shouldn't it be accessible to developers? Rather than break decentralization, this flexibility enables it IMO, so I think there is a misunderstanding somewhere. To enable some degree of Push service (and thus service provider) flexibility, I have also proposed that we could use Web Intents as a way to allow the user to select the service provider, but if the app has particular requirements (e.g. security or delivery methods/bearers), I see no reason why we should obfuscate the developer intent by making the user play the match maker. The requested service URL also provides means to negotiate additional functionality/options between the app and the Push service directly e.g. as above (e.g. security, delivery methods/bearers, application characteristics, ...). * I'm not sure why you have a |requestUrl| attribute in PushService. Do you have any use case for that? bryan The use case is that an app can have multiple Push service requests active at a time, with different URLs. In order to be able to associate each PushService object with a specific set of options or services for example, it needs to know what URL was used when the PushService object was created. The intent is similar to that of EventSource, which has the url attribute for a similar purpose (at least that is how I have used it). And since the checkRemotePermission() method needs to verify the permission for the same URL, it is better to have the resolved form of the URL available as an attribute, so that it's easy to call the checkRemotePermission() method for the right URL (as the absolute URL may have changed since the original resolution). * |readyState| should be a DOMString. bryan The jury is out on this, AFAICT. It's a short in EventSource and XHR. I was following their lead. * I guess the idea of |onmessage| is that the PushService instance will get an event when the backend will push a notification to the webapp. However, I wonder how you do handle the situation when the application is actually not being ran. Or should we wait
Re: Push API draft uploaded
On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html A couple of notes on the WebIDL: * PushManager has |PushService requestRemotePermission ([Optional] DOMString url);|, should be ... (optional DOMString url), though the spec doesn't appear to define what happens when url is omitted; same for checkRemotePermission. * There does not appear to be a need to make PushManager and PushService use [NoInterfaceObject], so please remove that. * PushService.readyState is a DOMString, but the spec defines it to return the unsigned short constants CONNECTING/OPEN/CLOSED. Please get rid of the constants. The requestUrl attribute must return the absolute URL where the webapp server can send Push service messages to this webapp. should probably refer to |serviceUrl|, not |requestUrl|. A reference to DOM4 for the DOMError interface should probably be added. Also, the resolve a url cross-reference is broken. HTH Ms2ger
RE: Push API draft uploaded
Thanks for the comments. I updated the spec: - define what happens when url is omitted - remove [NoInterfaceObject] - define readyState as a unsigned short (that was what was meant in the first place) - fix cut/paste errors I still have to find the source of resolve a url as that's a function I borrowed from EventSource. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.htm Thanks, Bryan Sullivan -Original Message- From: Ms2ger [mailto:ms2...@gmail.com] Sent: Thursday, May 24, 2012 12:33 AM To: SULLIVAN, BRYAN L Cc: public-webapps Subject: Re: Push API draft uploaded On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html A couple of notes on the WebIDL: * PushManager has |PushService requestRemotePermission ([Optional] DOMString url);|, should be ... (optional DOMString url), though the spec doesn't appear to define what happens when url is omitted; same for checkRemotePermission. * There does not appear to be a need to make PushManager and PushService use [NoInterfaceObject], so please remove that. * PushService.readyState is a DOMString, but the spec defines it to return the unsigned short constants CONNECTING/OPEN/CLOSED. Please get rid of the constants. The requestUrl attribute must return the absolute URL where the webapp server can send Push service messages to this webapp. should probably refer to |serviceUrl|, not |requestUrl|. A reference to DOM4 for the DOMError interface should probably be added. Also, the resolve a url cross-reference is broken. HTH Ms2ger
RE: Push API draft uploaded
Sorry, cut paste error: the spec is at: http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks, Bryan Sullivan -Original Message- From: SULLIVAN, BRYAN L Sent: Thursday, May 24, 2012 6:02 AM To: 'Ms2ger' Cc: public-webapps Subject: RE: Push API draft uploaded Thanks for the comments. I updated the spec: - define what happens when url is omitted - remove [NoInterfaceObject] - define readyState as a unsigned short (that was what was meant in the first place) - fix cut/paste errors I still have to find the source of resolve a url as that's a function I borrowed from EventSource. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.htm Thanks, Bryan Sullivan -Original Message- From: Ms2ger [mailto:ms2...@gmail.com] Sent: Thursday, May 24, 2012 12:33 AM To: SULLIVAN, BRYAN L Cc: public-webapps Subject: Re: Push API draft uploaded On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html A couple of notes on the WebIDL: * PushManager has |PushService requestRemotePermission ([Optional] DOMString url);|, should be ... (optional DOMString url), though the spec doesn't appear to define what happens when url is omitted; same for checkRemotePermission. * There does not appear to be a need to make PushManager and PushService use [NoInterfaceObject], so please remove that. * PushService.readyState is a DOMString, but the spec defines it to return the unsigned short constants CONNECTING/OPEN/CLOSED. Please get rid of the constants. The requestUrl attribute must return the absolute URL where the webapp server can send Push service messages to this webapp. should probably refer to |serviceUrl|, not |requestUrl|. A reference to DOM4 for the DOMError interface should probably be added. Also, the resolve a url cross-reference is broken. HTH Ms2ger
Re: Push API draft uploaded
Hi Brian, On 05/24/2012 03:02 PM, SULLIVAN, BRYAN L wrote: Thanks for the comments. I updated the spec: - define what happens when url is omitted - remove [NoInterfaceObject] - define readyState as a unsigned short (that was what was meant in the first place) - fix cut/paste errors I still have to find the source of resolve a url as that's a function I borrowed from EventSource. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks for the update. resolve a url is defined in HTML; see http://www.whatwg.org/html/#resolving-urls. As for a numeric readyState, please have a look at the discussion at http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0166.html. Finally, it appears that you removed [NoInterfaceObject] from NavigatorPush (where I believe it was correct), rather than from PushService. HTH Ms2ger
RE: Push API draft uploaded
OK, I corrected the [NoInterfaceObject] (I hope), and referenced HTML5 for resolving a URL. The numeric readyState was borrowed from EventSource. I will look at the thread, but I think this is something that I will just align with the consensus in the group once determined. I don't have a strong opinion either way. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks, Bryan Sullivan -Original Message- From: Ms2ger [mailto:ms2...@gmail.com] Sent: Thursday, May 24, 2012 6:37 AM To: SULLIVAN, BRYAN L Cc: public-webapps Subject: Re: Push API draft uploaded Hi Brian, On 05/24/2012 03:02 PM, SULLIVAN, BRYAN L wrote: Thanks for the comments. I updated the spec: - define what happens when url is omitted - remove [NoInterfaceObject] - define readyState as a unsigned short (that was what was meant in the first place) - fix cut/paste errors I still have to find the source of resolve a url as that's a function I borrowed from EventSource. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks for the update. resolve a url is defined in HTML; see http://www.whatwg.org/html/#resolving-urls. As for a numeric readyState, please have a look at the discussion at http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0166.html. Finally, it appears that you removed [NoInterfaceObject] from NavigatorPush (where I believe it was correct), rather than from PushService. HTH Ms2ger
Re: Push API draft uploaded
On 5/24/2012 7:08 AM, SULLIVAN, BRYAN L wrote: OK, I corrected the [NoInterfaceObject] (I hope), and referenced HTML5 for resolving a URL. The numeric readyState was borrowed from EventSource. I will look at the thread, but I think this is something that I will just align with the consensus in the group once determined. I don't have a strong opinion either way. Latest version is athttp://dvcs.w3.org/hg/push/raw-file/default/index.html Does the following mean that http/https are interpreted as EventSource and ws/wss as WebSockets? Does checkRemotePermission trigger CORS checks for those protocols? If the url parameter is present and the user agent recognizes the url value as a particular type of Push service that it supports, the user agent must activate the service. My read on that is yes and yes, but I wanted to double-check. -Charles
Re: Push API draft uploaded
Re a particular type of Push service that it supports this is intended to be generic so that new services (perhaps identified by unique URI schemes) can be covered under this. That being said, WebSockets schemes clearly would imply that protocol, but http schemes could be more flexible. One of the goals is to define how the serviceUrl is conveyed to the user agent and Webapp. In the process of determining that URL, there could be other useful info that the server returns, eg the applicable bearer bindings or info that will help ensure events can be delivered to the correct Webapp (e.g. SMS source address, message fields/headers). If its possible to define a lightweight and generic/extensible Push service registration protocol, this would be a good place to invoke it. We defined such a protocol for OMA Push, and some of those ideas might be useful here. This is an area for further study. If the Push server connection is setup to another domain then CORS would apply. But the checkRemotePermission method (at least as I understood it from the Mozilla proposal) would only test if there was a prior permission by the user, and would not need to invoke any network transactions to do so (though for some implementations this might be a feature). I will try to develop these ideas in the draft (or at least outline the intent to), but I did not want to put too much into it at this time... As far as possible I am leaning to the simple (but clearly not as simple as the Mozilla proposal). Service lifecycle management, of which registration is a facet, can hopefully be layered above the API for the most part. Thanks, Bryan Sullivan On May 24, 2012, at 9:33 AM, Charles Pritchard ch...@jumis.com wrote: On 5/24/2012 7:08 AM, SULLIVAN, BRYAN L wrote: OK, I corrected the [NoInterfaceObject] (I hope), and referenced HTML5 for resolving a URL. The numeric readyState was borrowed from EventSource. I will look at the thread, but I think this is something that I will just align with the consensus in the group once determined. I don't have a strong opinion either way. Latest version is athttp://dvcs.w3.org/hg/push/raw-file/default/index.html Does the following mean that http/https are interpreted as EventSource and ws/wss as WebSockets? Does checkRemotePermission trigger CORS checks for those protocols? If the url parameter is present and the user agent recognizes the url value as a particular type of Push service that it supports, the user agent must activate the service. My read on that is yes and yes, but I wanted to double-check. -Charles
