Regarding XIFF 3.0 July Updates

XIFF
1

Good afternoon,

This position is in regard to the July 06 subversion updates for XIFF version 3.0. While I noticed that the branch now has flex in the title, I don’'t think that asking the client of a production API (once this API is at such a level) to change the code of the API is realistic. Instead, why not create a derived class and interface for flash users?

Come now, object-oriented-programming is meant for flexibility. The derived class and interface that I spoke of are real possibilities with ActionScript 3.0, so why not use them? Changing code should not be a necessity of your future API.

There are instances where this could become a concern. If you cannot say that your API will work without the flex library out-of-the-box per se, and a company has policies against the flex library (a very real case), where does that place you?

I don’‘t take harsh subtense with this message. I simply want to see this product succeed. It’‘s the greatest of its class, and I’'m excited for its future.

Aaron Belovsky

2

I already update,but do not find login methed in the XMPPConnection.as. Variable myUsername seem to be not used, also have variable username don’'t know from where come of.

XIFF3.0 ought to provide some example.

3

Hello again,

I’‘m supplying a bug update today for an issue that occurs when requesting user affiliations with XIFF version 3.0 from SVN. Currently, the callback can’‘t fire when calling the library externally, because the callback function (finish_requestAffiliates) isn’‘t public. It’‘s private, and if one attempts to run the already public requestAffiliates function, he gets all kinds of lovely error output saying that finish_requestAffiliates doesn’‘t exist. Well, it does – the callback sequence just can’'t see it.

Below is the patched code for the two functions: requestAffiliates and finish_requestAffiliates. These functions may be found in the org.jivesoftware.xiff.conference.Room class. I suggest a more permanent patch, but this is a quick and dirty work-around. I simply made the finish_requestAffiliates function public. I’'ve highlighted areas of interest in blue text below.

/**

  • Requests an affiliation list for a given affiliation with with room.

  • This will either dispatch the event <code>RoomEvent.AFFILIATIONS</code> or

  • <code>RoomEvent.ADMIN_ERROR</code> depending on the result of the request.

  • @param affiliation Use one of the following affiliations: <code>Room.NO_AFFILIATION</code>,

  • <code>Room.OUTCAST_AFFILIATION</code>,

  • <code>Room.MEMBER_AFFILIATION</code>,

  • <code>Room.ADMIN_AFFILIATION</code>,

  • <code>Room.OWNER_AFFILIATION</code>

  • @see #revoke

  • @see #grant

  • @see #affiliations

*/

public function requestAffiliations( affiliation:String ):void

{

var iq:IQ = new IQ(getRoomJID(), IQ.GET_TYPE);

var owner:MUCOwnerExtension = new MUCOwnerExtension();

iq.callbackScope = this;

iq.callbackName = “finish_requestAffiliates”;

owner.addItem(affiliation);

iq.addExtension(owner);

getConnection().send(iq);

}

public function finish_requestAffiliates(iq:IQ):void

{

finish_admin(iq);

if (iq.type == IQ.RESULT_TYPE) {

try

{

var owner:MUCOwnerExtension = iq.getAllExtensionsByNS(MUCOwnerExtension.NS)[0];

var items:Array = owner.getAllItems();

var e:RoomEvent = new RoomEvent(RoomEvent.AFFILIATIONS);

e.data = items;

dispatchEvent(e);

}
catch (e:Error)
{

trace(“Error : null trapped. Resuming.”);

}

}

}

4

The same problem, as noted in the last post, also occurs on the private callback function “finish_admin” which should also simply be set to public as a temporary workaround. I should also note that I am working primarily with flash and that this class has already been modified to not require the flex library (see ArrayCollection).

5

Below is a replacement for the nickname property’‘s set function; also in the org.jivesoftware.xiff.conference.Room class. All I changed was getUserJID to getRoomJID, as it should be, in the highlighted text below. Why getUserJID actually works and returned the room’'s JID is another issue.

/**

*/

public function set nickname( theNickname:String ):void

{

if( isActive() ) {

pendingNickname = theNickname;

var tempPresence:Presence = new Presence( getRoomJID() + “/” + pendingNickname );

myConnection.send( tempPresence );

}
else {

myNickname = theNickname;

}

}

6

Hello again

Today, I was working with gathering a user count and a list of users from a XMPP server using XIFF 3.0. It seems that there’‘s still a little dysfunctional code left over from AS 2.0. The code I’'m attempting to execute is similar to the following:

import org.jivesoftware.xiff.core.XMPPConnection;

import org.jivesoftware.xiff.core.Browser;

import org.jivesoftware.xiff.data.IQ;

import org.jivesoftware.xiff.data.disco.ItemDiscoExtension;

var browse:Browser = new Browser(connection); //Assuming that a XMPPConnection has already been made successfully.

browse.getServiceItems(roomJID, “getUserList_finish”, this);

function getUserList_finish(resultIQ:IQ):void {

var disco:ItemDiscoExtension = resultIQ.getAllExtensionsByNS( ItemDiscoExtension.NS )[0];

var discoUsers = disco.items;

trace(“This room is occupied by " + discoUsers.length + " users.”);

}

The above code will retrieve a list of room items (users) and output the length of that array to a system trace. On execution, I received an error relating to the ItemDiscoExtension class not being instantiated with the proper number of arguments. It seemed that, on the callback, the ItemDiscoExtension was supposed to be able to take a null value. Unfortunately, and probably because of the AS 2.0 to 3.0 translation, the function is not written in this way.

To fix this issue, open ItemDiscoExtension.as, located at org.jivesoftware.xiff.data.disco.ItemDiscoExtension, and do the following:

Replace the constructor (lines 42-45):

public function ItemDiscoExtension(xmlNode:XMLNode)

{

super(xmlNode);

}

With the following:

public function ItemDiscoExtension(xmlNode:XMLNode=null)

{

super(xmlNode);

}

This will allow the constructor to take a null on callback and no more failures because of stupid error messages.

Enjoy,

-Aaron

7

Good find - just encountered the same problem. Any idea when this goes into the live version?

8

…once a nice patch is provided against the current svn version.

9

Against current trunk? I’m happy to do this, where should I put this patch?

We are also starting to add a few features of our own here, where can I post a message to see if the community would like these?

Thanks,

Michael

10

Hi,

Patches are most welcome.

You can post in the forum or to the issue tracker which is actually the preferred way, but requires an issue to exists for the certain bug/feature.

http://www.igniterealtime.org/issues/browse/XIFF