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

Iain Shigeoka iainshigeoka at yahoo.com
Wed Apr 24 21:40:33 UTC 2002

On 4/24/02 3:13 AM, "Dave Turner" <jabber at figroll.com> wrote:

> 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.

I would tend to agree.  At least the base protocol shouldn't make this
impossible (but the security model may restrict it).

>   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:
>       /london/office/temperature
>       /london/apartment/temperature
>       /boston/office/temperature
>       /boston/office/humidity

I like this idea.  I'm wondering though if we shouldn't just say that topics
are arbitrary text strings, and permit a restricted regular expression for
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.

Another way to define would be an arbitrary text name, and then
meta-information that we can attach for browse/search/filtering purposes.

>   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>

:) agreed.  Protecting the namespace in some moderately efficient way may be a
challenge though.  I've been thinking about this a lot with regards to a
Jabber: Next Generation (JNG) system.  The conclusion I'm slowly coming to is
that we must separate transport from data, and data can then separate content
from structure.  Of course, this doesn't help the current discussion...

> 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.

Perhaps we could go with persistent subscriptions with a queue limit... So you
persistently subscribe to a queue, but say you only want a maximum of 1 message
queued.  You can then disconnect.  Upon reconnection, you can rebind to the
queue, and your subscription can deliver the queued messages.  This is similar
to JMS persistent queues.

> 4.  My last idea, and this might take some waffling to make my point.
>   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
>   example.

This is a feature that I really like.  Coming from Java Jini (www.jini.org) I
firmly believe that leased resources is critical to creating a robust system. 
Since we're queue oriented, the idea of creating arbitrary wills to be sent
after death is extremely powerful.   You've definitely got my vote on this one!


Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more

More information about the Standards mailing list