[standards-jig] JEP-0024: Publish/Subscribe - Topic based messaging

Dave Turner jabber at figroll.com
Fri May 10 20:34:14 UTC 2002

On Mon, Apr 29, 2002 at 07:59:20AM +0100, Piers Harding wrote:
> >     can generate a lot of traffic but I don't think that it is the place of the
> >     protocol to restrict the ability to do this.  There may be some valid
> And lastly - other than your logging example - I can not think of any
> example of an application that would beable to deal with all the

Actually, I can't either.  I just don't like to see message being oppressed. ;o)

>  namespace is an arbitrary string of data ( admitedly with restrictions
> on what you can use to creat ethat string ) - it is entirely up to your

I'll buy that.  I was thinking that maybe by being an xml namespace there is more
constraint on the value.

> The use of wild card subscriptions is interesting, but it is still an
> implementation issue.

Point taken.  I was thinking too low level.

> For "subscription realm" ( or topic I guess - for want of a better name
> ), the idea that we had was that the client woud luse IQ Browse to
> discover a list of things to subscribe to.  It would be a feature of the
> browsing client to allow wild card selection of items to subscribe too.
> JEP0024 allows for multiple subscription requests in a single packet.

I had in mind that the clients would normally be programmed to publish and/or
subscribe to particular topics so that browsing would not be relavent.  However,
for an interactive program I really like that idea.

> > 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.
> Why does historical information have to be bound up in the same protocol
> as pubsub?  Why wouldnt that be yet mor einformation exposed by the
> publisher thru a browse function?

Yep, I guess that would work if by browsing you mean the subscriber browsing
the broker by some given topic.  One thing that I think is very important is
for the subscribers to be completely independant of the publishers.

> >     Simply put it is handy to be able to set a 'Will' message that a publisher
> >     can have published on their behalf (so that it seems to have come from
> It sounds quite specific - I would have thought that this could be
> achieved thru TTLs on subscriptions.  A client re negotiates it's
> subscription - when it browses to the publisher it finds it unavailable.

There may be more than one publisher producing data on a given topic.  The Will
message may not necessarily be saying "I am offline" it could be something
useful like "shutdown the core".

I think that browsing publishers goes against the idea of pub/sub messaging.
Afterall, by putting logic into the subscribers to request specific data from
a specific publisher, aren't you just developing another protocol?

Dave Turner

More information about the Standards mailing list