Hi,
My question pertains to how IM Services (e.g. Yahoo, AIM, etc.) handle/damage Xmpp resource qualifiers.
Specifically, if I send a message to the AOL network can I expect the gateway to preserve the resource for the return message?
Example:
from this jid: "userA@myserver.com/fooResource"
to "aimuser@aim.myserver.com"
Desired Usecase:
-
“aimuser” presses enter in his/her AIM client,
-
the XMPP server receives a message sent back to the original jid, "userA@myserver.com/fooResource"
-
XMPP Server routes the response “by resource” to the resource which sent the original message.
My experience:
AIm/Gateway routes to the ‘bare’ Jid (userA@myserver.com). The app server routes based on the server configuration: i.e. either to the last active session or to all sessions.
If I cannot configure the XMPP or the IM Gateway to handle this, can anyone suggest workarounds?
thanks,
bill
Not as is, no. Because there’s no thread or anything I can carry through to the legacy service to really attach XMPP message to AIM message. In other words, XMPP message A. comes in, I convert it to AIM message B, AIM message C comes back, but there’s nothing I can pass to AIM to have any idea that the return message has anything to do with XMPP message A.
Now, there’s a possible way to get around this that could be coded into the gateway plugin. Lets say you have three resources:
Priority 10: /ninja
Priority 5: /work
Priority 1: /monkey
Those are in order of top priority. so CURRENTLY, all incoming messages will go to /ninja. Now lets say a message comes in from /monkey. The response is going to go to priority 10. I agree this sucks.
A way we -could- get around this is to record the last resource we got a message from on the XMPP side and treat that as the “temporary” top priority resource. So while number 10 might be really on top. For the IM Gateway plugin’s purposes, number 1 is, until something arrives from /ninja, or /work, or maybe even we do some sort of timeout of how long we’re willing to leave it at the top.
The problem here comes in as the following scenario:
-
/monkey sends a message, now it’s at the top of the list
-
you walk away from /monkey
-
someone messages you and /monkey receives it
-
you go to /ninja and don’t see the message that went to /monkey
In theory /ninja is the top of the line and should have gotten the message, but unfortunately due to the “special hack” we’d have in place, now priority rules aren’t being followed.
In theory, the best way to handle this would be for the client you are chatting with, say with resource /monkey, should set it’s priority to something high for the duration of the time where it wants to be the receiver of messages from AIM/etc.
Hi Monsieur Jadestorm,
Hmmm…A very thorough answer, one confirming my suspicions, but not the answer I had hoped for. The “by resource” routing works so well with standard xmpp, I had hoped it would work with the gateway.
To clarify it sounds like this:
When AIM (or yahoo or msn) sends a message to an xmpp server (e.g. openfire), the server has no way to determine the resource originally associated with the “thread”.
My first instinct was “hack bosh,” i.e. write http binding servlet that will “add back” the resource information. The servlet may know the resource for the original “outgoing” message (http request). But any incoming message may or may not belong to the original “thread”. Thus the bosh/http-binding layer cannot correctly “add back” the resource information.
Our intended functionality: add a “anonymous asking” layer for IM. I.e. our webapp would have one “generic xmpp account”, completely with gateway registrations for AOL, Yahoo, etc. Webapp users would use this shared account via an HTML/ajax IM client to send/receive IM’s to other users AOL/Yahoo/etc. accounts. The “shared account” would have as buddies the “other users AOL/Yahoo/etc” users.
“Shared account? hackish!,” you probably think. Yet it works (in theory) nicely as people it allows a trusted intermediary to ‘pre-qualify’ contacts and reduces the number of “buddy list connections” for N users from N-Factorial number down to N.
Looks like we’ll need another plan.
bill