There are several problems with the existing browse spec... I've been working on a few (protocol-wise) - this discussion should probably move to the standards JIG Julian ----- Original Message ----- From: "Jens Alfke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, 16 August, 2001 12:37 Subject: [JDEV] Ambiguity in jabber:iq:browse "pushes" > 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.) > > --Jens > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
