[standards-jig] JEP-0024: Publish/Subscribe - Topic based messaging
dj.adams at pobox.com
Sat May 11 13:35:35 UTC 2002
On Wed, Apr 24, 2002 at 11:13:26AM +0100, Dave Turner wrote:
> I have a few comments/ideas to add regarding the pub/sub proposal.
Sorry for the delay in responding, I hope it's not too late to add
my thoughts/agreements; my brain 'connect time' currently is very
> 1. I realised that subscribing to all messages from all publishers
> 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
> reason to want to subscribe to everything, a logging application for example.
> It should be down to the programmer of the application to take care not
> to do this if the system isn't going to be able to cope.
This is a fair comment, and even though Piers made the good point about
logging seeming to be the only application of this */* (and that perhaps
the pubsub component itself should do that anyway), it could be argued
that this should be implementation, rather than specification. We could,
at the very least, add it to an implementation notes list as an addendum
if we thought it necessary to change.
> 2. I think that the notion of using namespaces for published messages puts
> restrictions on the protocol. Maybe it's just my misunderstanding of how
What you have in mind is actually exactly what Piers and I had in mind,
what with the hierarchical subjects as you have shown here (our canonical
example during cafe discussions was an auction house/price one, where
there's a hierarchy of auction categories:
And indeed, your later point about wildcards also figured in our
discussions and intentions:
So yes, agreed, thanks for bringing these points up,
it serves as good clarification.
> As a side note, in this sort of situation it is almost certainly beneficial
> to acutally publish XML data rather than raw data, such as:
> <temperature scale="centigrade">14</temperature>
> so as not to lose meaning in the data. But that's not a pub/sub thing so
> I'll ignore that from now on.
> Ok, I think I've made the point that I wanted to about wildcards. Now, this
:-) You did. It was well made. And agreed with :-)
> 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.
> This should also be complemented by an attribute in the publish message
> to tell the broker NOT to honour requests for the last message.
This is an interesting one. It's not state-free pubsub, nor is it data-storage
pubsub. I've heard this requirement (desire?) elsewhere too, which makes
it doubly intriguing.
The key point for me is the 'On subscription' bit. I.e. this forwarding of
the last message to be received (from the publisher) only happens (on
request) at subscribe time. It's not a "oh I've dropped some data, what was
the last thing you said?" kind of thing (although this could be achieved
by the subscriber un- and re-subscribing. Ugh.)
> 4. My last idea, and this might take some waffling to make my point.
Don't worry - I waffle professionally, sometimes ;-)
> 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
> them) if they have stopped responding. Let me explain why with a SCADA
This is also very interesting (thanks for all your input, btw. Much
appreciated). Knee-jerk reaction: if this was to be part of the specification,
I'd imagine it sitting better as a(n optional) _extension_ to the protocol
(sort of 'iq:pubsub:will', if you will) rather than 'muddying' the
clear and simple waters.
Ok, time to go to watch a football match
More information about the Standards