Re: Matching tags

On Wed, Jun 20, 2012 at 6:36 AM, James Graham <jgraham@opera.com> wrote:

> On 06/20/2012 03:19 PM, John Gregg wrote:
>
>> On Wed, Jun 20, 2012 at 4:13 AM, James Graham <jgraham@opera.com
>> <mailto:jgraham@opera.com>> wrote:
>>
>>    It seems like when tags match the old notification is replaced by
>>    the new notification. This seems confusing (and possibly hard to
>>    implement?) if there is any substantive difference between the
>>    notifications. Why not just discard the new notification?
>>
>>
>> Part of the point of the tag (previously known as "replaceId") is to
>> update a notification.  One motivating use case is a chat application
>> (see section 7.3 of the spec) -- rather than many incoming chats from
>> the same person causing multiple notifications or only the first one,
>> the application can consolidate or update as it prefers.
>>
>
> Hmm, but the spec as written it doesn't seem to work for the case where
> you have two mail windows open and they both want to display the same
> notification about the same incoming mail; if you have a notification
> system where the text can't be updated in-place then afaict it will look
> like two different notifications.
>

The new spec says that if the notification system doesn't support it, it
"can be addressed by removal and addition instead".  I agree that's a
little vague; the goal is to have only one notification where the newer one
wins.

The previous language was:
    5. If the underlying notification platform supports replacement,
replace old with new on the device.
    6. If the underlying notification platform does not support
replacement, remove old from the device and show new on the device.

Anne, can we restore that language consistent with the new task structure?