Re: Publishing Web Notification Drafts

On Wed, Oct 13, 2010 at 11:38 AM, Doug Turner <dougt@dougt.org> wrote:
>
> On Oct 13, 2010, at 10:15 AM, Drew Wilson wrote:
>
>> Overall this looks good. A few comments:
>>
>> 1) To address Doug's earlier comment about dropping things like "dir" and "replaceId" - I'd be concerned about omitting these. The use cases around "dir" seem fairly well established, and replaceId likewise seems strongly grounded in use cases and is already supported by some system platforms (I believe growl supports this, no?).
>
> I do not think so?
>
> [GrowlApplicationBridge
> notifyWithTitle:(NSString *)title
> description:(NSString *)description
> notificationName:(NSString *)notificationName
> iconData:(NSData *)iconData
> priority:(signed int)priority
> isSticky:(BOOL)isSticky
> clickContext:(id)clickContext]
>
>
>> I'd like our API to be driven by our use cases and requirements, and not by the functionality exposed by any specific current system platform, as the latter may change over time at the whims of various development teams.

Well, it's also important that the API can be implemented. Since we
want to integrate with platform APIs where possible, this does put
some limitations on the API.

This is nothing new, we've always been limited by what is
implementable. That is after all why we have the CR phase as well as
one of the reasons why we want implementors involved in the spec
process.

> Maybe.
>
> If we add such attributes, they should be optional.

Optional attributes must be added with a lot of care. We generally
work really hard to make sure that APIs work the same across
implementations. It is well known that few authors read the spec to
see what can and cannot be depended on. It is very common that authors
write something, test it in one, maybe two, browsers, and then release
to the public.

/ Jonas

Received on Wednesday, 13 October 2010 18:52:24 UTC