Re: [whatwg] Notifications: in workers

On Fri, May 17, 2013 at 8:13 AM, Andrew Wilson <atwilson@google.com> wrote:
> On Thu, May 16, 2013 at 5:45 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> So how would that work if open gmail.com twice, in two distinct
>> browsing contexts? Long term we want those to be able to use distinct
>> threads I think, but they should be able to share a single event
>> page/worker.
>
> I'll have to ping the gmail team to ask what they did there in their
> prototype.

Thanks. I think this is probably the most interesting bit. Next is
whether doing it on the main thread would be actively hostile to a
future parallel world.


>> Not having the ability to focus (draw attention to) and open windows
>> does seem like something we should solve. (The cross-origin loading
>> case you mentioned should really be solved using WebSocket or CORS. I
>> heard from at least one guy from your app team that they want to move
>> to something like that long term and the <iframe> thing is mostly a
>> intermediate hack.)
>
> The <iframe> thing (and other <script>-based solutions like JSONP) are
> definitely hacks, but they are hacks with a fairly long history in the web
> world. Agreed about CORS, although we've been talking about CORS support in
> workers for a while now with no implementations AFAIK - maybe we just need a
> compelling feature like this to drive teams to actually build it.

There's a difference between cross-origin workers and cross-origin
fetching from workers. I meant the latter.


>> That seems like something we want to support, no? E.g. you get a push
>> message, so you open the event page/worker, and that dispatches a
>> notification, but then you want to kill the event page/worker so it
>> doesn't continue to use system resources. Couple days later the user
>> might click the notification and then you'd open the event page/worker
>> again.
>
> Agreed, I think this is a valid use case once you support event
> pages/workers as targets for notifications (it also probably has some uses
> for things like server-initiated notifications, where the server can specify
> a URL to navigate to when the user clicks, although I've never really paid
> attention to the server-initiated notification discussions so I don't quite
> follow their use cases).

I think even if we didn't have event pages/workers we'd still want to
support end-user notifications that remain in the notification center
after the page has been closed (or crashed or whatever). Use cases for
push notifications are basically "new email", "new instant message",
"new photo from friend", while the page/app is not open (communicating
the push notifications should probably be done through either end-user
notifications or spawning some kind of window (although the latter
would be pretty disruptive).


--
http://annevankesteren.nl/

Received on Friday, 17 May 2013 10:56:34 UTC