Hi All,
I run my own public IM server (atomic-im.yi.org) and have several clients hooked up to it at any one time. 90% of the time, my desktop machine will be connected, and often, at least one client such as my Octane or my laptop. I use Kopete on all machines (v0.12.3 on the desktop… v0.11.? on the Octane), which seems to handle the gateways well.
I have all four IM gateways enabled (MSN, Yahoo, ICQ, AIM) and have accounts registered for each of them. With one client connected, everything works well. Apart from some group-chat issues with MSN, I’'m able to communicate with everyone.
However, if I connect a second client, I’'m not able to redirect the gateway traffic to the new client. Messages get directed at the old client. If I kill the connection to the old client, then the agents come online and messages appear on the new client.
I tried forum searching, but can’‘t see anything similar to this. WildFire is a great server app, and so far, JustWorks. Just need to solve this annoyance and it’'ll be perfect.
Ohh… I should mention… I’'m running WildFire 3.1.1 and IM Gateway 1.0b6 on Sun Java 1.5.0 for Linux (i386).
Regards,
Stuart Longland (Jabber: redhatter@atomic-im.yi.org)
Message was edited by: Redhatter
I’‘m actually surprised groupchat even tries to work. ;D I haven’'t even begun that functionality!
However, if I connect a second client, I’'m not able to redirect the gateway traffic to the new client. Messages get directed at the old client. If I kill the connection to the old client, then the agents come online and messages appear on the new client.
When you say another client, are you referring to another client connecting to the same JID? Messages from the gateways always go to the client with the highest priority (which is normal XMPP behavior) … or at least they should be. ;D If they’‘re not that’‘s certainly bad. Now lets assume for the moment that the second client you connected with had a lower priority than the first one… you still should have seen all of the online/whatever presence of your contacts. It sounds like, at a minimum, that’'s not working. Does this sound accurate?
I tried forum searching, but can’‘t see anything similar to this. WildFire is a great server app, and so far, JustWorks. Just need to solve this annoyance and it’'ll be perfect.
Ohh… I should mention… I’'m running WildFire 3.1.1 and IM Gateway 1.0b6 on Sun Java 1.5.0 for Linux (i386).
Just to make sure, 1.0 Beta 6b?
Redhatter wrote:
Regards,
Stuart Longland (Jabber: redhatter@atomic-im.yi.org)
Message was edited by: Redhatter
Hi All,
I run my own public IM server (atomic-im.yi.org) and have several clients hooked up to it at any one time. 90% of the time, my desktop machine will be connected, and often, at least one client such as my Octane or my laptop. I use Kopete on all machines (v0.12.3 on the desktop… v0.11.? on the Octane), which seems to handle the gateways well.
I have all four IM gateways enabled (MSN, Yahoo, ICQ, AIM) and have accounts registered for each of them. With one client connected, everything works well. Apart from some group-chat issues with MSN, I’'m able to communicate with everyone.
jadestorm wrote:
I’‘m actually surprised groupchat even tries to work. ;D I haven’'t even begun that functionality!
Indeed… it does try to perform the group chat, but it appears as multiple one-to-one conversations.
However, if I connect a second client, I’'m not able to redirect the gateway traffic to the new client. Messages get directed at the old client. If I kill the connection to the old client, then the agents come online and messages appear on the new client.
When you say another client, are you referring to another client connecting to the same JID? Messages from the gateways always go to the client with the highest priority (which is normal XMPP behavior) … or at least they should be. ;D If they’‘re not that’‘s certainly bad. Now lets assume for the moment that the second client you connected with had a lower priority than the first one… you still should have seen all of the online/whatever presence of your contacts. It sounds like, at a minimum, that’'s not working. Does this sound accurate?
This is correct… they have the same JID, and for the most part, same priority.
Even with one client connected, sometimes I’‘m finding the MSN transport is refusing to connect. At the moment I’'m on a Win32 box running psi; Yahoo, ICQ and AIM all successfully connected… MSN remains offline.
I tried forum searching, but can’‘t see anything similar to this. WildFire is a great server app, and so far, JustWorks. Just need to solve this annoyance and it’'ll be perfect.
Ohh… I should mention… I’'m running WildFire 3.1.1 and IM Gateway 1.0b6 on Sun Java 1.5.0 for Linux (i386).
Just to make sure, 1.0 Beta 6b?
This is correct.
jadestorm wrote:
I’‘m actually surprised groupchat even tries to work. ;D I haven’'t even begun that functionality!
Indeed… it does try to perform the group chat, but it appears as multiple one-to-one conversations.
What would you say is your preference with that? I think that seems a little confusing so I would lean towards… I ought to disable group chat acceptance and such. (I’‘m assuming that’'s possible)
However, if I connect a second client, I’'m not able to redirect the gateway traffic to the new client. Messages get directed at the old client. If I kill the connection to the old client, then the agents come online and messages appear on the new client.
When you say another client, are you referring to another client connecting to the same JID? Messages from the gateways always go to the client with the highest priority (which is normal XMPP behavior) … or at least they should be. ;D If they’‘re not that’‘s certainly bad. Now lets assume for the moment that the second client you connected with had a lower priority than the first one… you still should have seen all of the online/whatever presence of your contacts. It sounds like, at a minimum, that’'s not working. Does this sound accurate?
This is correct… they have the same JID, and for the most part, same priority.
Same priority? That’‘s most likely causing some confusion. I’‘m not really sure what happens when two entities have the same priority … last one to log in? I’‘m almost positive my code doesn’‘t handle that well. Apparently that’‘s allowed though as you wouldn’‘t be able to log in otherwise. Sheesh… I just don’‘t know how I would be expected to tell which one is “in charge” with the same priority. Perhaps the best I can do is let them fight it out. =/ I would bet that’‘s what’‘s causing the issues you are seeing though. Basically I have a hashed array of priority to resource mapping. But it’'s one priority to one resource.
Even with one client connected, sometimes I’‘m finding the MSN transport is refusing to connect. At the moment I’'m on a Win32 box running psi; Yahoo, ICQ and AIM all successfully connected… MSN remains offline.
Hrm. Might just be a legit failure to connect. Interestingly enough, every time I try to connect to MSN from the official mac MSN client, I get a failure first and have to retry. (sigh)
I tried forum searching, but can’‘t see anything similar to this. WildFire is a great server app, and so far, JustWorks. Just need to solve this annoyance and it’'ll be perfect.
Ohh… I should mention… I’'m running WildFire 3.1.1 and IM Gateway 1.0b6 on Sun Java 1.5.0 for Linux (i386).
Just to make sure, 1.0 Beta 6b?
Redhatter wrote:
This is correct.
jadestorm wrote:
Redhatter wrote:
jadestorm wrote:
I’‘m actually surprised groupchat even tries to work. ;D I haven’'t even begun that functionality!
Indeed… it does try to perform the group chat, but it appears as multiple one-to-one conversations.
What would you say is your preference with that? I think that seems a little confusing so I would lean towards… I ought to disable group chat acceptance and such. (I’‘m assuming that’'s possible)
That is an option. The fact that it half-works now, suggests it’'s possible to make it work properly… Is there source code available for this plugin somewhere? I might be able to rig something up here.
However, if I connect a second client, I’'m not able to redirect the gateway traffic to the new client. Messages get directed at the old client. If I kill the connection to the old client, then the agents come online and messages appear on the new client.
When you say another client, are you referring to another client connecting to the same JID? Messages from the gateways always go to the client with the highest priority (which is normal XMPP behavior) … or at least they should be. ;D If they’‘re not that’‘s certainly bad. Now lets assume for the moment that the second client you connected with had a lower priority than the first one… you still should have seen all of the online/whatever presence of your contacts. It sounds like, at a minimum, that’'s not working. Does this sound accurate?
This is correct… they have the same JID, and for the most part, same priority.
Same priority? That’‘s most likely causing some confusion. I’‘m not really sure what happens when two entities have the same priority … last one to log in? I’‘m almost positive my code doesn’‘t handle that well. Apparently that’‘s allowed though as you wouldn’‘t be able to log in otherwise. Sheesh… I just don’‘t know how I would be expected to tell which one is “in charge” with the same priority. Perhaps the best I can do is let them fight it out. =/ I would bet that’‘s what’‘s causing the issues you are seeing though. Basically I have a hashed array of priority to resource mapping. But it’'s one priority to one resource.
Ahh okay. Perhaps a better way to do this… is to have the user when on a particular resource, pings the plugin at a nominated JID to tell it where to send the messages? To change the priority of a resource, requires re-logging in, which gets rather messy, especially when you don’'t have access to the machine running the resource.
Even with one client connected, sometimes I’‘m finding the MSN transport is refusing to connect. At the moment I’'m on a Win32 box running psi; Yahoo, ICQ and AIM all successfully connected… MSN remains offline.
Hrm. Might just be a legit failure to connect. Interestingly enough, every time I try to connect to MSN from the official mac MSN client, I get a failure first and have to retry. (sigh)
MSN is a rather difficult service … I use it only because most people I know use it – otherwise I try to encourage them to use XMPP. The pain that is proprietary IM systems. If everyone saw the light, this plugin would be completely unnecessary.
Redhatter wrote:
To change the priority of a resource, requires re-logging in
That’‘s not true. The priority is part of the presence packet, you can change that on the fly. There’'s even a XEP about telling the other resource connected to the same jid to change its presence. Of course, this has to be implemented on both clients to work.
jadestorm wrote:
Same priority? That’‘s most likely causing some confusion. I’‘m not really sure what happens when two entities have the same priority … last one to log in? I’‘m almost positive my code doesn’‘t handle that well. Apparently that’‘s allowed though as you wouldn’‘t be able to log in otherwise. Sheesh… I just don’‘t know how I would be expected to tell which one is “in charge” with the same priority. Perhaps the best I can do is let them fight it out. =/ I would bet that’‘s what’‘s causing the issues you are seeing though. Basically I have a hashed array of priority to resource mapping. But it’'s one priority to one resource.
This should be handled better. It’‘s not a requirement for two resources to have different priorities (otherwise the server would have to reject one of those), it’‘s even the default (since you’'d have to alter the priority manually in the client).
anlumo wrote:
jadestorm wrote:
Same priority? That’‘s most likely causing some confusion. I’‘m not really sure what happens when two entities have the same priority … last one to log in? I’‘m almost positive my code doesn’‘t handle that well. Apparently that’‘s allowed though as you wouldn’‘t be able to log in otherwise. Sheesh… I just don’‘t know how I would be expected to tell which one is “in charge” with the same priority. Perhaps the best I can do is let them fight it out. =/ I would bet that’‘s what’‘s causing the issues you are seeing though. Basically I have a hashed array of priority to resource mapping. But it’'s one priority to one resource.
This should be handled better. It’‘s not a requirement for two resources to have different priorities (otherwise the server would have to reject one of those), it’‘s even the default (since you’'d have to alter the priority manually in the client).
Right… but that’‘s what I was asking, how do I know which resource to send to if they’‘re both the same priority? Both? Just pick the one that’'s alphabetically first? Pick the one that logged in most recently? Check the phase of the moon and pick a random one?
Redhatter wrote:
That is an option. The fact that it half-works now, suggests it’'s possible to make it work properly… Is there source code available for this plugin somewhere? I might be able to rig something up here.
It is indeed! Go to Downloads → Source and note the SVN links. Check out wildfire’‘s tree and then look in src/plugins/gateway. The groupchat/muc functionality was discussed a while ago with the Jive folk and they were going to work on a generic but easy interface for me to use for groupchats, but it hasn’‘t come to pass as of yet. If you happen to come up with somethnig that’‘d be great! Note that I really don’'t care about full on MUC support yet, just would like to see groupchat minimally. Either way, if you have time to look at it and submit me some patches, that would be awesome!