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 develope
On 6/6/12 6:05 PM, "SULLIVAN, BRYAN L" 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
>requireme
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" wrote:
>On 05/31/
On 06/05/2012 09:27 PM, Tobie Langel wrote:
> On 6/5/12 4:00 PM, "Mounir Lamouri" 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
>>> us
On Tue, 05 Jun 2012 21:27:57 +0200, Tobie Langel wrote:
Overall, I feel like writing down use cases and requirements would be
something useful to do at this point. What do you think?
Definitely.
cheers
--
Charles 'chaals' McCathieNevile Opera Software, Standards Group
je parle français
On 6/5/12 4:00 PM, "Mounir Lamouri" 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 applic
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 cons
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" wrote:
>>> * I guess the
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
On 5/30/12 11:14 AM, "Mounir Lamouri" 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 r
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
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
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
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
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
Thanks for the comments. Some responses added as
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
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
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 he
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 t
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 o
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
n'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
Subjec
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
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 hav
27;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
Subjec
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
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/A
27 matches
Mail list logo
