[standards-jig] JEP-0024: Publish/Subscribe - Topic based messaging
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?
More information about the Standards