proposal: browse-only functionality

[mick <mg...@redhat.com>]

QPID-4241

Some messaging applications require browse-only functionality.  Readers
of messages are never allowed to 'consume' the messages, because those
messages will always be relevant to newly arriving subscribers.  ( Or at
least their loss of relevance is orthogonal to how many users have
already seen them. )

Browse-only functionality could be accomplished by constraining users,
through the ACL system, or by constraining queues at declaration time.

The two approaches are not equivalent, and both would probably be
worthwhile to implement at some point.  The ACL approach would be nice
to have someday, because in many browse-only applications the *readers*
of messages do not determine their useful lifetime, but the *writers*
do.

Right now, however, the user who needs this functionality would be
satisfied by either approach, the queue-declaration looks definitely
easier, and we need both someday anyhow.  

So I'd like to implement browse-only queues.

Here is a proposed functional specification.

I'd be thrilled to hear any feedback.  Please express your input as 

  * email
  * edits to Jira QPID-4241
  * slide decks
  * anonymous messages on my answering machine
  * youtube rap-music videos
  * interpretive modern dance




      proposed functional specification - 2
      {
        purpose
        {
          Some users need browse-only functionality. For example,
          messages represent the an ongoing history of events,
          all of which are relevant to newly joining consumers.
          The messages should remain unconsumed and available to
          newcomers until they are outdated by time-to-live rules,
          thrown away by a ring-queue, or the queue is destroyed.
        }


        strategy note
        {
          ACL and browse-only-queue solutions to this problem are
          both possible.  But right now we should prefer a
          browse-only-queue solution, because

            (1) it would satisfy the current customer's requirements,
             and
            (2) the ACL functionality requires a complete overhaul.
        }


        user interface
        {
          1. extend x-declare{arguments:{}} in our addressing
             to include 'browse-only'.

          2. queues that are declared "browse-only" will allow
             subscribers to access queues, and 'acquire' messages
             normally -- but that 'acquisition' in this queue would
             result in only a browse.  The message would remain.

          3. no effect on ACLs.
        }


        testing
        {
          As user mick, use standard command line tools to:

            1. declare a queue with browse-only argument.

            2. use standard command line tool to send N
               messages to the queue.

            3. use standard tool to 'consume' messages from
               queue.  Confirm that N messages are read.

            4. Repeat step 3 at least once, and confirm that
               same N messages are again read every time.
               ( They are not consumed. )

            5. Set TTL on messages and confirm that it removes
               messages from queue.

            6. Confirm same behavior across all queue types.
        }
      }




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: proposal: browse-only functionality

[Gordon Sim <gs...@redhat.com>]

On 08/23/2012 02:29 PM, mick wrote:
> QPID-4241
>
> Some messaging applications require browse-only functionality.  Readers
> of messages are never allowed to 'consume' the messages, because those
> messages will always be relevant to newly arriving subscribers.  ( Or at
> least their loss of relevance is orthogonal to how many users have
> already seen them. )
>
> Browse-only functionality could be accomplished by constraining users,
> through the ACL system, or by constraining queues at declaration time.
>
> The two approaches are not equivalent, and both would probably be
> worthwhile to implement at some point.

Agreed.

The ACL approach is preferable where you want a mixture of consumers and 
browsers and want only certain users to be able to consume.

A queue option that makes the queue browse only is useful when you don't 
want the receivers to have to care whether they are browsing or not, 
i.e. where you want to control the distribution behaviour at the queue 
rather than through each subscription request.

> So I'd like to implement browse-only queues.

Sounds reasonable to me. It will strictly speaking be a 'violation' of 
the AMQP 0-10 specification, but since it is explicitly configured that 
is I think quite acceptable.

AMQP 1.0 provides better ways to manage the distribution centrally but 
alerting consumers to the fact that they are not actually consuming in 
case that is something they want to treat as an error. 9E.g. through the 
first-acquirer header on delivered messages or the distribution mode on 
the link source).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org