Re: CfC: FPWD of Web Notification drafts

On Mon, Oct 18, 2010 at 5:29 PM, Doug Turner <dougt@dougt.org> wrote:

> Hey Drew,
>
> > The latter case (replaceId) is definitely possible with system
> notifications on Linux (NotifyOSD)
>
> true.  I suppose replaceId is important.
>
> > and I don't see how similar functionality can be achieved with a
> callback.
>
> You will get an onclose() and you could put a new notification up at that
> point... but that assumes that notifications are not sticky.
>

A relevant use case is: the user has their calendar webapp open in two tabs
when it's time to display a reminder to the user. ReplaceID ensures that the
user sees only a single notification (not N notifications where N = "the
number of pages that have the page open". I don't think "display a new
notification on onclose()" can achieve this same result. It sounds like
we're now on the same page that replaceId is important, though.


>
> I want the first rev of this spec to be about the minimal support that
> common native systems already have.  Further revisions can include
> additional things.
>

What "common native systems" should we include in addition to Growl and
NotifyOSD? I'd vote to include WebOS, which exposes a notification API with
scriptable HTML content. Any others?



> > I can't state categorically whether URL notifications are in or out of
> the scope of our charter, but I will note that NotifyOSD supports a subset
> of HTML:
> >
> > https://wiki.ubuntu.com/NotifyOSD#sanitizing
> >
> > Can you clarify why you believe that this is out of the scope of the
> charter?
>
> Oh, that is something totally different, it think.  NotifyOSD allows you to
> pass html as the description and have it be rendered.  The WebNotification
> as part of this spec allows you to specify remote content and have that be
> rendered.
>

OK, so you're saying it's the ability to pass in a URL that you feel is out
of the scope of the charter because it does remote (network) access? Can you
clarify which part of the charter that violates?

The only relevant language in the charter that I can find is this:

"The platform-independent specifications produced by this group should be
designed to be implementable using existing native notification mechanisms.
Since the common platforms do not provide consistent functionality, this
specification will indicate what features are guaranteed to be available
across platforms, and what features are not."

Given that HTML notifications could be implemented using NotifyOSD (and are
fully supported by WebOS), this seems to imply that this functionality is
within the scope of the charter. The only other reason I could see that we
would exclude WebUrlNotifications() would be if it failed to meet the "two
independent implementations" criteria due to lack of implementor interest
(as you say, Mozilla is not interested in this API at this time) - I believe
that only becomes an issue when we are trying to move to the Proposed
Recommendation stage, though, and my hope is that this spec will gain more
support as it matures.

-atw