[
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
