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 _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
