Avoiding/swatting duplicate notifications for client generated subscriptions

[Wanicki, Martin]

Duplicate notification swatting has always been something I've tried to
avoid like the plague, but the introduction
of client generated susbcriptions makes duplicate notifications entirely
more possible.

I am of the belief that all hand built subcriptions should function normally
and if a couple of these bring in duplicate notifications
it is the responsibility of the user to sort out their subscriptions.

However, clients implementing transient subscriptions and temporary
subscriptions created for the sole purpose of ensuring
the client gets its own notifications back, will possibly cause a client to
recieve the same notification against more than one subscription.

To overcome this and at the same time leave the user defined susbcriptions
to behave as normal, I have come up with a simple
approach that seems to work and offer it here for your comment.

The approach is based on the use and implementation ot the 'Replacement'
field in the Tickertape notification format spec.

ONLY on notifications received against client-generated or automatic
subscriptions do the following ...

Upon reciept of such a notification inspect the notification for the
existence of a 'Replacement' attribute, 
if it doesnt exist add the attribute and copy the contents of the
'Message-Id' field into it.
Then let your normal code do the the rest.

If your client has implemented the replacement attribute and functionality
you should never see more that one 
instance of the notificaion in your message threads or in the scroller.

Cheers

Martin