I basically concur, but here's a bit more detail (and a few more items
to consider):
- 1.4 concerns the ability for a consumer to pull instead of having
messages pushed at it
- 1.8 calls for a document on how to administrate WSN. It will
need to take into account whatever mechanisms we come up with.
- 2.6 concerns the need to allow for DDOS mitigation mechanisms
like double opt-in
- 2.13 concerns binding of message formats for consumers, i.e., how
do you negotiate what form a consumer will get its messages in
- 2.18 concerns the ability to garbage collect subscriptions by
means other than scheduled termination. I'd definitely include it.
- 2.26 concerns delivery to multiple consumers (I believe this is
essentially 1-of-N delivery)
- 2.27 concerns the ability to queue and replay messages
- 2.28 concerns delivery in the face of process failures
- 2.30 is the WSDM partial notification issue
- 3.2 concerns the format of messages from Publisher to broker
Note also that the existing configurable parameters (notably useNotify
and the topic and filter dialects) imply some sort of negotiation
mechanism.
Hi All:
A quick scan through the "issues
list" suggested the following issues have some affinity to "use
of policy in WSN":
1.4, 2.6.(maybe 2.18), 2.20, (maybe)
2.26, 2.28,
Would it be possible to start the
policy
discussion with a use case related to whatever motivated the issue to
be
raised?
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
|