On Sat, Nov 05, 2005 at 10:04:01PM +0100, Jakob Schroeter wrote:
> Hi Lou,
>
> On Saturday November 5 2005 20:09, you wrote:
> > I am implementing RosterListener. When a user goes "away", I get an
> > itemChanged event. When that user comes back, I get an itemAvailable
> > event. Is that the way it is supposed to work? I would have expected
> > to get another itemChanged event when they come back.
>
> Well, sort of. On XML level both events are identical. An app has to track on
> its own whether a user was away or offline when an 'available' presence
> arrives. The RosterManager currently just forwards the event.
> There is certainly room for improvement here.
>
>
> > I am trying to work around that behaviour, and it is certainly doable,
> > but, from my POV, it doesn't seem quite right.
>
> How about the attached patch, does it achieve what you expect?
You know, it's funny. My code has jumbled around so much today that I
cannot reproduce the problem now.
I'm thinking, that maybe I should have my itemUnavilable and
itemAvailable methods just call my itemChanged method and handle
everything there. I just have a big switch on PresenceStatus in there
anyway. Clearly, other people/projects are using gloox with no problem
as it is, so I should be able to too.
I'm trying to wrap my head around all of the methods of a
RosterListener. The difference between itemChanged and itemUpdated, for
instance. I gather that the former relates to local changes in the
RosterItem, and the latter relates to changes that came from the server.
So I'm not sure why I'm seeing itemChanged getting called instead of
itemUpdated. I am not doing any local modification of the roster. That
is just one example of where I appear to be lacking in my mental picture
of how this is all supposed to work.
I think it is more a matter of getting myself using the library
correctly, than one of changes being needed. But thank you for taking
the time to create the patch. It looks good to me, what I can
understand of it, but, as I said, I cannot reproduce the behaviour right
now. It may be a worthwhile change for future versions, but, then
again, it might require people to rework their code to accomodate the
new behaviour, which might be more harm than good.
--
gloox-dev mailing list
to unsubscribe:
send a message with subject 'unsubscribe gloox-dev' to minimalist@xxxxxxxxxx