Subscribe type both

XIFF
1

Hi Sean Voisen,

I’'m wondering if there is a current way to add a contact with a presence request of the type “both”.

I took a look at the Roster class and it did not seem like you have this ability at the moment.

I also noticed this comment in the addContact() method which I think is relevant to what I’'m talking about:

// We can directly add this contact without updating our roster. We also

// need the roster item for changing the subscription type (if requested)

//

// XXX Sean, please review this and remove this comment

It looks like right now you just have it set I automatically like this:

subscription = RosterExtension.SUBSCRIBE_TYPE_TO;

Could we simply add another parameter to the addContact() method that would represent the subscription type? So, then you could do the following:

myRoster.addContact( "homer@springfield.com", “Homer”, “Drinking Buddies”, true, “both” );

It can also still be defaulted to “to”, so that people that don’'t want to specify then it will work the way it does now.

I can implement this and send it along to you if you wish, although if you have another plan for this feature let me know.

Let me know your thoughts on this when you get a chance.

Thanks,

Chris

///

Actually now that I think about it more, maybe you should change the requestSubscription parameter to be a String instead of a Boolean, and you could specify “none”, “to”, or “both” there. The problem with this approach of course, is that it breaks exisitng code that uses the Boolean value.

Message was edited by:

callen

2

Chris, you bring up an interesting point because I didn’'t even realize this code was in there (the code below the comment and the code specifying subscription types). The other Sean must have added it.

The way I had thought about it orignally was for the server to do the work and push the new roster item to the client rather than the client automatically add the new item to roster without server intervention.

According to the XMPP spec, you don’‘t even specify the subscription type when adding a contact. You send the IQ then the server responds with subscribe type ‘‘none’’. And this is when the roster gets updated with the new contact. Then you proceed with the subscription process. Of course, the code doesn’‘t even work this way now that I look at it. It basically ignores the server’'s response IQ.

So, I guess I don’‘t see the harm in adding an option for type “both” but I also wondering now if it’‘s not better to change the code and wait to update the roster for the server response rather than add it automatically anyway (what if the server goes down? The user would have the illusion that the contact was successfully added to the roster when in fact it wasn’'t.)

What do you think?

See section 8.2 of http://www.xmpp.org/specs/rfc3921.html

3

Chris, you bring up an interesting point because I

didn’'t even realize this code was in there (the code

below the comment and the code specifying

subscription types). The other Sean must have added

it.

That makes sense. It sure is confusing having both of you guys with the same name.

According to the XMPP spec, you don’'t even specify

the subscription type when adding a contact. You

send the IQ then the server responds with subscribe

type ‘‘none’’. And this is when the roster gets

updated with the new contact. Then you proceed with

the subscription process. Of course, the code doesn’'t

even work this way now that I look at it. It

basically ignores the server’'s response IQ.

So, I guess I don’'t see the harm in adding an option

for type “both” but I also wondering now if it’'s not

better to change the code and wait to update the

roster for the server response rather than add it

automatically anyway (what if the server goes down?

The user would have the illusion that the contact was

successfully added to the roster when in fact it

wasn’'t.)

What do you think?

I think that we should change it so that we do indeed wait for the IQ response for adding to the roster. This way we can get the confirmation that it has been done on the server before proceeding. It would be nice fore the Roster class to do it all automatically so that when you run addContact() this stuff is all taken care of and then the client can receive an event like “Roster.subscriptionSuccess” that could have in its eventObject the JID of the user that you successfully added to your roster. we could possibly add another event for when in the unlikely event you never get a response back. Some kind of time out perhaps? Although this could be overkill considering any stable XMPP server should always respond. And we know when and if the socket connection dies.

So, I guess in short, I reccomend changing the code so that we do update the client-side roster only when the server responds.

It would be nice to be able to add a contact and have the recipient do the same on the other end but this doesn’'t seem possible according to the XMPP specs. Let me now if you can think of a way to accomplish this.

Thanks,

Chris

4

Yes, I would agree with your recommendation Chris - I’‘m going to see if I can check with the “other Sean” to see if there was some good reason he did it that way. Chances are there is (there’'s also the chance I wrote that code and totally forgot!)

5

Sounds good to me. Let me know if I can help in anyway.

-Chris