[standards-jig] JEP-0060 comments
greg at hewgill.com
Sun Jan 5 16:57:10 UTC 2003
On Thu, Jan 02, 2003 at 01:36:46PM -0700, Peter Millard wrote:
> * Added a jid attribute to the subscription element when subscribing:
> Note that for iq transactions, the server must send back TO the full jid,
> since JSM will not route iq packets which do not have a resource.
I'm still a bit confused about this. Suppose I want to subscribe from an entity
using the full jid? In my application, I'm thinking of having a small desktop
component that runs under the credentials of an existing Jabber user, with a
different resource name. This desktop component would subscribe to a node and
would expect to receive notifications when items are published. Therefore, the
pubsub component must know about the full jid which expects to receive
notifications. Perhaps a modification to this sentence would help:
> Otherwise, the jid in the <subscribe> element must match the bare jid in the
> "from" attribute
Could this say, "Otherwise, the bare part of the jid in the <subscribe>
element..."? In this way, an entity can request that notifications be delivered
to it specifically.
> I would think the ID's should be unique for a given node. If someone
> publishes with the same node, and implementation may over-write the old
> item, or give an error?
Are item IDs optional? It seems that requiring item IDs, and requiring that
they also be unique for a node (otherwise an error is returned), is an
unnecessarily strict constraint. I would think that given this constraint, most
publishers would end up using something like a timestamp or an incrementing
number for each item ID.
If items IDs are unique and overwritten if an item with the same ID as an
existing item is published, then it is no longer possible for clients to
retrieve an accurate history of published items using the get items
For example, consider a music player notifier that announced which track it was
playing. Perhaps it could announce each track with id="track", and each new
album with id="album" (let's assume that new albums happen less frequently than
new tracks). If unique ids were not required (as in my current implementation),
then subscribers could request the current album by getting the item with id
"album" and the current track by getting the item with id "track". They could
also retrieve an accurate history of both albums and tracks with the max_items
> In the baseline specification, I think batching should not be included, as
> it can always be layered on top of this or just by using something other
> "wrapper" protocol.
Fair enough, as long as the baseline protocol allows for the possibility. With
the new jid= attribute on the subscribe request (and presumably on the
unsubscribe request), this should be easier.
I'm working on taking your other updates into account in my implementation.
More information about the Standards