Thanks David. I like the
simplicity. A few comments:
1) I'd rather not say in BaseN
how the producer advertises the maximum limit on number of messages
(because this would require either metadata support or WS-ResourceProp
which we don't currently need for the simple cases). Or at the very
least, if we really have to define a QName for this information, make
it a MAY rather than a MUST.
2) I'd like to add the
possibility for the subscriber to set the max number of messages to
retrieve (actual number could be less if fewer events have been emitted
or if the producer can't store that many). Either as part of each
GetStoredMessages request or once as part of the subscription.
3) I am fine with the
information about the dropped messages being an optional element rather
than a notification as I originally proposed.
My logic for (2) is that I see
pull-type used in cases where the producer is very capable (access to
large and reliable storage mechanism) but the consumer is lightweight.
The limited party here is the consumer and the producer accepts to do
more work to help out the consumer. So the consumer should be able to
decide how many messages to retrieve, not the producer who might not
understand the constraints that the consumer is under and the goals
that the consumer has in retrieving this information.
Regards,
William
Intended Application:
This proposal is aimed at configurations in which the consumer, perhaps
because of a firewall or other security measure, is unable to receive
notifications directly. To support this, we offer a basic facility for
storing and forwarding notifications. This facility is not intended to
cover all possible cases of pull-based delivery. It is expected that
the consumer will poll the delivery address reasonably frequently
relative to the rate of notifications.
Policy:
NotificationProducers MAY advertise a pull notification
capability. If so, they MUST advertise a maximum limit on the number
of messages to be stored for a given pull subscription. Subscribers
MAY request pull notification when making a subscription. In such a
case, the ConsumerReference element MUST be empty. The
SubscrptionPolicy element MUST indicate [exact spelling TBD]
that pull notification is requested.
Delivery of notifications:
The response to the subscribe request MUST provide an endpoint through
which the consumer may retrieve messages. This endpoint MUST support
the GetStoredMessages request/reply. The GetStoredMessages request is
empty. The GetStoredMessages reply MUST contain, in order, the most
recent notifications for the subscription since the previous
GetStoredMessages request (or in the case of the first
GetStoredMessages request, since the subscription was established), up
to the limit advertised by the NotificationProducer. If the limit was
exceeded, the response MUST also include the number of notifications
produced but not delivered for the current request. [This probably
means a Notify message plus an optional "messages dropped" element]. Note
that the GetStoredMessages response may contain no messages at all. [TBD
whether this is just an empty Notify message or something yet smaller].
In all cases, the GetStoredMessages response should be delivered
promptly, as opposed to delaying until a message arrives.