[standards-jig] JEP-0024: Publish/Subscribe - Topic based messaging
jabber at figroll.com
Thu Apr 25 10:26:27 UTC 2002
On Wed, Apr 24, 2002 at 02:40:33PM -0700, Iain Shigeoka wrote:
> > I think that topics should be heirachical in the same way as a directory
> > name, for example. So I could publish messages on topics such as:
> defining the topic you wish to subscribe to... Naming conventions can then be
> suggested, but aren't mandatory. So if you need structure, you can have it,
> but if you don't, you have full freedom to get weird.
I think the issue here is defining at what level the structure needs to be
defined. We need to consider the publisher, subscriber, and brokers'
interpretation of the topic. The broker is especially important because
it needs to route messages in a smart way.
One thing that I was intersted in finding/developing a robust pub/sub messaging
system was to play with some ideas I had for efficient routing of messages
over a federated network of brokers.
pub1 is connected to broker1 and sub1 and sub2 are connected to broker2.
broker2 needs to request that broker1 sends it messages on topics that
are the superset of the topics requested by sub1 and sub2.
If there is some minimal structure that the broker can rely on then this
set should calculatable. Sorry, I've not had enough coffee yet to think
up an interesting example.
> Another way to define would be an arbitrary text name, and then
> meta-information that we can attach for browse/search/filtering purposes.
Hmm... that could be interesting. The Dublin Core Metadata Initiative 
might have some interesting material on this. I have been working with
some of the DCMI elements. There might be scope there.
> > 3. On subscription to a topic it would be convenient to elect to receive
> > the last message that was published on that topic, if one is available.
> Interesting. From an efficiency standpoint, this could place a big burden on
> the server though. You'd never be sure when a message is done and can be
> discarded from a queue because someone can always come along and request the
> last x messages.
I was only thinking of keeping the last 1 message at the broker. The premise
of event based pub/sub messaging is that each message supercedes the previous
one on a given topic. This is of course from the topic based pub/sub point
of view, so maybe multiple queued messages is the correct generalization.
I just realised that my example subscribe request was a bit ambiguous in this
I'm interested in the point you raise about determining when a message is
'done'. Obviously, the broker isn't the place to decide this. The publisher
however, having best understanding of the data, can set a TTL on the message
and the broker can cull messages when they become too old. That would be
a nice option to have. If a TTL isn't defined the message can persist forever
making this transparent to the clients if they don't support it.
More information about the Standards