[JDEV] Ambiguity in jabber:iq:browse "pushes"

[Dave Waite]

Jens Alfke wrote:

> I'm trying to grok the vague description of jabber:iq:browse on the 
> "Protocol-Draft" section of the DocZone:
>     http://docs.jabber.org/draft-proto/html/browsing.html
> As always, if this is the wrong thing to look at and there's a 
> conflicting but more accurate description somewhere else, let me know!
>
> The primary thing that's gotten me confused is the apparent ambiguity 
> of a "set" query using this namespace. It seems to be used for two 
> entirely different things:
> (1) Sent to a watcher as a "push" to notify a watcher of new data in 
> the *sender*s browse space.
> (2) Sent to a browse source to edit (add/modify/delete) data in the 
> *receiver*s browse space.
>
> In general I don't see how these two things can be distinguished from 
> each other. If you look at the two examples in the "Live Browsing" and 
> "Editing" sections, they are fundamentally identical; only the type of 
> data elements in the payload is different. Yet the two have very 
> different meanings and in fact describe data on two different JIDs! 
> The sinking feeling I have is that when receiving such a "set" you 
> have to make a judgment call based on the exact type of data contained 
> and the exact JID you received the query from. I imagine that this is 
> _usually_ possible, but it makes me nervous and doesn't seem like a 
> good design.
>
> IMHO it's the "push" feature that seems wrong -- it's a misuse of 
> "set". The exact meaning of "get" and "set" is already pretty vague 
> due to all the uses they've been put to, but it seems that you can at 
> least rely on the fact that they apply to the _receiver_ of the query. 
> But browse pushes turn this on its head.
>
> What this really points out is the lack of a general purpose 
> subscription/notification mechanism in Jabber, which is ironic since 
> this is so central to presence. Jabber's <presence> element and its 
> subscription model are completely hardwired for one particular type of 
> data (presence state and status text) and cannot be used for anything 
> else. There is a lot of other info that one might want to subscribe 
> to, ranging from buddy icons to lists of shared files to news 
> headlines, but no good mechanism to manage the subscriptions and 
> notifications required by real-time updates of this information.
>
> Any comments? Am I totally off-base here? Are the existing efforts to 
> remedy this? (I'm aware of the Profiles JIG and have just joined it.)

As far as I understand, if the JID of the top element within the browse 
matches the JID being requested, it is a replace. If it doesn't match, 
then you are representing a child and are doing an insert/modify/delete.

-David Waite