Rosters and Presence.Type relationships?

Smack Smack Dev
1

This is a question pertaining to the most basic of chat programs, nothing fancy or odd in behaviour.

I’‘m wondering what the Roster should display, depending on the Presence.Type(s). For example, I’‘ve noticed that when I send out a SUBSCRIBE, a RosterEntry is added to my Roster (but unfiled). I’'ve created a PacketListener for the SUBSCRIBED packet which then calls addEntry() and connects the RosterEntry to the appropriate RosterGroup. However, this initial unfiled RosterEntry – should it even appear on my roster display gui?

As a work-around, I guess I could just assume that any unfiled RosterEntry’‘s are not yet SUBSCRIBED and so I can ignore the unfiled RosterEntry’‘s altogether. However, this would also prevent me from creating any SUBSCRIBED RosterEntry’‘s that also do not have a particular RosterGroup. In other words, is it appropriate to force all SUBSCRIBED RosterEntry’'s into a (even if arbitrary) RosterGroup?

I’‘ve also noticed that when someone sends me a SUBSCRIBE request, even before I can respond (accept/denial), their RosterEntry has already been added to my Roster, and therefore displays on my roster display gui as an unfiled RosterEntry. I can see these unfiled RosterEntry’'s from random SUBSCRIBE requests getting rather numerous, quickly, and sometimes, I may not even want them! Are they automatically purged at some point, or do I have to manually call removeEntry() for each to get them out of my Roster?

Another aspect of this issue is the denial of SUBSCRIBE requests – if I don’‘t want someone to SUBSCRIBE to my presence, what should the denial response packet’'s Presence.Type (if any) be? Should it be an UNSUBSCRIBE? Or just ignore the initial SUBSCRIBE request and never send a SUBSCRIBED? Maybe send an ERROR?

Moving on to UNSUBSCRIBE – is it appropriate to expect a RosterEntry to be online to reply to an UNSUBSCRIBE request with an UNSUBSCRIBED reply before calling removeEntry() to remove the RosterEntry from the Roster? Or should removeEntry() be called first, then an UNSUBCRIBE packet be sent, just in case, but to no real consequence whether a reply is received?

Sorry for the berth of questions – if no direct answers can be provided here, is there documentation elsewhere that would provide such answers?

Thanks!

Message was edited by:

big_magnus

2

Hey big_magnus,

I’'m wondering what the Roster should display,

depending on the Presence.Type(s). For example, I’'ve

noticed that when I send out a SUBSCRIBE, a

RosterEntry is added to my Roster (but unfiled). I’'ve

created a PacketListener for the SUBSCRIBED packet

which then calls addEntry() and connects the

RosterEntry to the appropriate RosterGroup. However,

this initial unfiled RosterEntry – should it even

appear on my roster display gui?

You may want to read the following specification to understand how does this thing work. XMPP | XMPP RFCs. In summary, when you add

someone to your roster and ask to subscribe to his presence your client will have a roster entry with presence subscription = SUBSCRIBE. That means that you are still waiting for the contact to accept or deny the presence subscription request. Usually, clients show a ? icon next to the contact or something that gives the impression that the contact is pending to answer the request. Meanwhile, you can move your roster entry to any groups you want or just leave it in the unfiled group.

Having an entry in the unfiled group just means that it doesn’'t belong to any group. It has nothing to do with the presence subscription status.

I’'ve also noticed that when someone sends me a

SUBSCRIBE request, even before I can respond

(accept/denial), their RosterEntry has already been

added to my Roster, and therefore displays on my

roster display gui as an unfiled RosterEntry. I can

see these unfiled RosterEntry’'s from random SUBSCRIBE

requests getting rather numerous, quickly, and

sometimes, I may not even want them! Are they

automatically purged at some point, or do I have to

manually call removeEntry() for each to get them out

of my Roster?

By default, Smack will accept all presence subscriptions. If you want to do it manually, you will have to send Roster#setDefaultSubscriptionMode(Roster.SUBSCRIPTION_MANUAL) and register a listener for presence packets. Read the Roster class documentation for more information.

Regards,

– Gato