[Standards-JIG] JEP-0060 (pubsub) Event Types

Ralph Meijer jabber.org at ralphm.ik.nu
Sat Jun 26 18:35:17 UTC 2004

On Sat, Jun 26, 2004 at 02:16:12PM -0400, Bob Wyman wrote:
> Ralph Meijer wrote:
> > If the publisher would send no payload along in the publish,
> > how can the pubsub service persist the item?
> 	The way JEP-0060 is currently written, it seems clear that you
> can publish with no itemID and with no payload. The pubsub XSD is clear
> about the fact that the item element which would otherwise contain the
> payload is an optional child of <publish> (i.e. it has minOccurs=0).
> Thus, the following would be a minimal publish request:
> <iq type="set" from="xxx" to="xxx" id="publish1">
>   <pubsub xmlns="http://jabber.org/protocol/pubsub">
>     <publish node="generic/pgm-mp3-player"/>
>   </pubsub>
> </iq>
> 	Ralph seems to be suggesting that the minimal request should
> look like the following (itemID would remain optional, but item would
> become required):
> <iq type="set" from="xxx" to="xxx" id="publish1">
>   <pubsub xmlns="http://jabber.org/protocol/pubsub">
>     <publish node="generic/pgm-mp3-player">
>       <item/>
>     </publish>
>   </pubsub>
> </iq>
> 	Personally, I see no significant semantic difference between the
> two and prefer the first (the way things are currently written) since it
> requires at least 16 fewer bytes in every request of this type. In
> either case, any system which is persisting data is probably going to
> simply store an empty node, some marker for "no item", or simply an
> empty string. In some cases, this may require a slight increase in the
> complexity of the persistence code, however, that added complexity is a
> tiny cost when balanced against the cost of increasing the size of every
> publish request by 16 bytes.

No no, that is not my point. The idea of a node that is persistent but
doesn't send out the payload in the notification (the left-top cell of table
2), is that you can detect that something has changed in the node AND that you
can retrieve the payload via the item id (see the prosa in 8.1.3). However,
this means that the pubsub service would have to know the actual payload.
Right? So it does make sense that the /notification/ has an empty item element,
but surely the /publish/ needs the payload in it.

The minimal publish you mention is for the bottom-left case, where the
node is not persistent (transient) and the node is configured to send
out 'empty' notifications.

Surely, an item's payload may be empty if that's useful for the application
when we are not in the bottom-left case.



More information about the Standards mailing list