Re: [wsn] Proposal for "simple pull"

[Peter Niblett <peter_niblett@uk.ibm.com>]

The default for Push-style notification is that you get just a single
message. We are only going to enable boxcarring via a policy option.
Shouldn't we adopt the same approach for Pull? In other words have a
GetStoredMessage rather than GetStoredMessages, and return only one message
at at time, unless the subscriber indicates in a policy that box carring is
required.

Also, I presume, messages may get dropped during push notification, but we
don't tell the consumer about this.

I'd like to argue for symmetry between push and pull, and that anything
other than the simplest set of pull options should have to be enabled via
subscription policy.

Peter Niblett



                                                                           
             David Hull                                                    
             <dmh@tibco.com>                                               
                                                                        To 
             15/02/2005 14:05          "Vambenepe, William N" <vbp@hp.com> 
                                                                        cc 
                                       wsn@lists.oasis-open.org            
                                                                   Subject 
                                       Re: [wsn] Proposal for "simple      
                                       pull"                               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




On further thought, I think giving the consumer a means to limit the number
of messages is a good idea, and it seems pretty cheap as well.  If the
consumer can limit volume, then there's no problem with the NP's limit
being optional.

In other words, +1.

Vambenepe, William N wrote:
      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

      From: David Hull [mailto:dmh@tibco.com]
      Sent: Monday, February 14, 2005 11:03 AM
      To: wsn@lists.oasis-open.org
      Subject: [wsn] Proposal for "simple pull"

      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.