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: [email protected]
For additional commands, e-mail: [email protected]
