Re: [Push API] Fine-grained unsubscription

2016-04-04 Thread Jonathan Garbee
I come across the "Are You Sure?" when unsubscribing from email lists a
lot. I don't think it is something we should allow, it is annoying and
sounds condescending to people. I'm making a choice to press this thing, i
mean it.

I think it is best if sites simply offer notification preferences in their
settings and when a user initially allows for notifications then you alert
them that the preferences exist to control which ones you send.

I think what is currently offered is right, if the user chooses to opt-out,
just let them without friction. It is up to sites to not spam users with
unwanted notifications anyways, not for users to prune what types they see
to not be notified as much.

On Mon, Apr 4, 2016 at 3:39 PM Marco Colli  wrote:

> Currently the user can turn off notifications for a website directly from
> the browser. When he unsubscribes all notifications from that website are
> turned off.
>
> However, it is a common practice (for example with email) to allow the
> user to turn off only some topics (i.e. fine grained preferences). I think
> this is a must for push notifications too.
>
> A simple way to implement this would be to add an editPreferencesUrl
> option to the pushManager.subscribe(). Then, when the user clicks the wheel
> to turn off push notifications sees two options: "Turn off all
> notifications" and "Manage push preferences on the website". When he clicks
> the latter is sent to the editPreferencesUrl on the website.
>
> It would also be very useful to be able to display a custom message before
> the unsubscription happens. That message can appear above the unsubscribe
> actions.
>
> Another option would be to have a callback *before* the unsubscription:
> that callback can show a single prompt to the user with a custom message
> (e.g. "Are you sure? Remember that you can visit example.com if you want
> to turn off only some notifications").
>
>
> Marco Colli
> Pushpad (https://pushpad.xyz)
>


Re: [XHR]

2016-03-19 Thread Jonathan Garbee
If I understand correctly, streams [1] with fetch should solve this
use-case.

[1] https://streams.spec.whatwg.org/

On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas
>  wrote:
>
> > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse the
> > chunked transfer coding”. The logical interpretation of this is that
> > whenever possible HTTP recipients should deliver the chunks to the
> > application as they are received, rather than waiting for the entire
> > response to be received before delivering anything.
> >
> > In the latest version this can only be done for “text” responses. For any
> > other type of response, the “response” attribute returns “null” until the
> > transmission is completed.
>
> How would you parse for example an incomplete JSON source to expose an
> object? Or incomplete XML markup to create a document? Exposing
> partial responses for text makes sense - for other types of data
> perhaps not so much.
> -Hallvord
>
>