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

[Julian Missig]

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" <jens at mac.com>
To: <jdev at jabber.org>
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
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>