[JDEV] possible defect in RosterList behavior

Keith Minkler kminkler at jabber.com
Tue Feb 13 16:13:05 CST 2001


Jay,

    This behavior is definitly by design.  The Roster updates come in the form of roster "pushes".  You must first request the roster, so that you have a working copy of the roster, in order to recieve any changes.  since pushes only represent a *change* to the roster, that is of no use to a client, unless they have the full roster to change.  

    This behavior is also due to the fact that if a simple client (i.e. one that does not even have a roster) does not request the roster from the server, that means that they do not wish to have any thing to do with the roster.. therefore, the server should not be sending it roster updates, as the simple client does not even display the roster. (i.e. when another client changes the roster, it gets sent to all connected clients that have requested roster updates).

    NOTE also, that a similar effect is true for subscription(s10n) notices.. you will not get any s10n requests if you have not sent you presence, due to the same logic.. If a simple client, or an "invisible" client does not send their presence, then they want nothing to do with presence based notifications at all.

    It will be possible in the future for clients to also tell the server what kinds of messages they wish to handle.. i.e. a client can notify the server that they can *ONLY* handle headlines, all other messages will be routed to another client, or stored offline.

    Hope this helps,
        Keith Minkler


On Tue, Feb 13, 2001 at 02:03:03PM -0800, Jay Chalfant wrote:
> I noticed today that I won't get any roster item updates from Jabber server
> until I request the entire roster list. Specifically, unless I first do a 
> 
> <iq id="doroster_4" type="get">
>   <query xmlns="jabber:iq:roster" /> 
> </iq>
> 
> I won't get roster updates as I make changes to the roster. I don't see any
> documentation that justifies this behavior so I assume it is a defect. I
> believe it should be considered a defect because the protocol should not
> require a client to retrieve the roster list every time it connects just to
> be able to use the roster list. (We have a specific justification for not
> receiving the roster list on every request.)
> 
> Here is a sample sequence (ignore the xml annotation):
> 
> - <jabberproxy_add_buddy>
> - <SEND>
>   <presence type="subscribe" to="jchalfan at aimtrans.internal.outbackinc.com"
> /> 
>   </SEND>
> - <SEND>
> - <iq id="982087708" type="set">
> - <query xmlns="jabber:iq:roster">
>   <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="_jchalfan" /> 
>   </query>
>   </iq>
>   </SEND>
> - <RECV>
>   <iq id="982087708" type="result" from="a at billabong/I at P"
> to="a at billabong/I at P" /> 
>   </RECV>
> - <RECV>
> - <presence to="a at billabong"
> from="jchalfan at aimtrans.internal.outbackinc.com">
>   <status>Idle 0 Minutes</status> 
>   </presence>
>   </RECV>
>   </jabberproxy_add_buddy>
> 
> This sequence occured in a session in which I had not requested the whole
> roster list. If I do request the roster list first, I get what I consider is
> a "normal" protocol behavior which includes the 4 (!) roster updates and the
> reverse subscribe request as shown below.
> 
> - <winjab_add_buddy>
> - <SENT>
> - <iq id="JCOM_34" type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan">
>   <group /> 
>   </item>
>   </query>
>   </iq>
>   </SENT>
> - <SENT>
> - <presence to="jchalfan at aimtrans.internal.outbackinc.com" type="subscribe">
>   <status>Normal Subscription Request</status> 
>   </presence>
>   </SENT>
> - <RECV>
> - <iq type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan"
> subscription="none">
>   <group /> 
>   </item>
>   </query>
>   </iq>
>   </RECV>
> - <RECV>
>   <iq id="JCOM_34" type="result" from="a at billabong/a_310"
> to="a at billabong/a_310" /> 
> - <iq type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan"
> subscription="none" ask="subscribe">
>   <group /> 
>   </item>
>   </query>
>   </iq>
> - <presence to="a at billabong" type="subscribed"
> from="jchalfan at aimtrans.internal.outbackinc.com">
>   <status>Normal Subscription Request</status> 
>   </presence>
> - <iq type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan"
> subscription="to">
>   <group /> 
>   </item>
>   </query>
>   </iq>
> - <presence to="a at billabong" type="subscribe"
> from="jchalfan at aimtrans.internal.outbackinc.com">
>   <status>Normal Subscription Request</status> 
>   </presence>
> - <presence to="a at billabong"
> from="jchalfan at aimtrans.internal.outbackinc.com">
>   <status>Idle 0 Minutes</status> 
>   </presence>
>   </RECV>
> - <SENT>
>   <presence to="jchalfan at aimtrans.internal.outbackinc.com" type="subscribed"
> /> 
>   </SENT>
> - <RECV>
> - <iq type="set">
> - <query xmlns="jabber:iq:roster">
> - <item jid="jchalfan at aimtrans.internal.outbackinc.com" name="jchalfan"
> subscription="both">
>   <group /> 
>   </item>
>   </query>
>   </iq>
>   </RECV>
>   </winjab_add_buddy>
> 
> Can someone please clarify if this is a bug or a "feature".
> 
> thanks,
> 
> -J
> 
> 
> 
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010213/65bea7b0/attachment-0002.pgp>


More information about the JDev mailing list