Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] review for xmpp provider bug

Hi Eugen,

It's been a while since I worked a lot directly with XMPP so my memory is a little fuzzy...but if it's your code that's connecting these two clients, you might want to have B send a presence update once it connects (I don't think that the server handles this for you automatically...although memory caveat above applies).

Also...you can/could also register IRosterListeners for roster contents/additions/changes if you need that in your client.

Scott

Eugen Reiswich wrote:
Hi Folks,

"good" to read that bug because I've ran into a similar problem with XMPP (I checked out ECF from repository and updated it today). I try to connect two clients with an XMPP server. I've registered on both clients an IPresenceListener because I would like to be informed if new user connect or existing user disconnect:
getRosterManager().addPresenceListener(new IPresenceListener() {
public void handlePresence(ID fromID, IPresence presence) {
...

But the odd thing is (might be due to the lack of my XMPP knowledge) that handlePresence behaves different than expected:
1. connect user A
2. connect user B
User B get's a notification --> user A is online
User A does not get a notification that user B has logged in.

I tried this out for a long time and it seems sometimes to depend on the sequence I connect clients. But sometimes it doesn't. Is this problem related to that one you've emailed or is this normal XMPP behavior?

Cheers,
Eugen


Am Jun 14, 2010 um 23:54  schrieb Scott Lewis:

Hi Folks,

Just to let everyone know...this fix did *not* get added to Helios/ECF 3.3. To be applied/released to HEAD/ECF 3.4, however, some further usage and testing of the patch (on bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=316071) in multiple environments would/will still be appreciated.

Thanks,

Scott


Scott Lewis wrote:
Hi Folks,

I guess I neglected to say that if we can get this fix reviewed and approved before Wed, June 9 (tomorrow) around noon, it can make it into Helios. If no one can review before then, we will probably have to wait until after Helios (as RC4 final...tomorrow is supposed to be final non-emergency Helios build).

Thanks,

Scott

Scott Lewis wrote:
Hi Folks,

This bug was just discovered/reported: https://bugs.eclipse.org/bugs/show_bug.cgi?id=316071

It has to do with how gmail calculates/returns the client resource ID. Our implementation wasn't taking into account that the server can set the resource ID to something different than the client specifies on login.

The fix (as patch/attachment) fixes this issue by using the resource provided by the server as the resource for the XMPPID.

If we can get a review by a couple of committers I believe we might could get this fix into Helios release. It would be nice if we could do this (get into Helios)...especially for Matt and/or other XMPP remote service users/consumers. The risk introduced by the fix is low.

Are there some ECF committers (who hopefully have worked some with the XMPP provider) who could review my patch on the bug and approve it? If so, then we could move forward with releasing to HEAD. If not, then no sweat...we'll get into a later release.

Thanks,

Scott






_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/ecf-dev

------------------------------------------------------------------------

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev



Back to the top