Hi Lou,
> 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.
Well, no, and yes. The former relates to status changes of a RosterItem, going
from available to away, for example.
The latter announces changes to the item initiated by another instance of your
jabber ID, connected with another resource. This other resource could have
changed the subscription state, or the name of the contact as stored in the
roster on the server, or the group that item belongs to. These kind of
changes are propagated by a so-called roster-push, i.e. the server pushes the
updated roster item to all connected resources of your jabber ID.
If you modify your roster locally and commit (synchronize()) the changes, you
get an itemUpdated, too, because it is pushed to the initiating resource as
well.
> 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.
If you get an itemChanged after the item changed its status that's the
expected behaviour.
> I think it is more a matter of getting myself using the library
> correctly, than one of changes being needed.
Keep those questions coming. It helps me understand and fix the shortcomings
of lib and docs. After all, I created the interfaces how I thought they might
make sense and they were not tested for usability in real applications.
> 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.
I consider the current behaviour a bug. I have plans to revamp all the Roster*
classes, so this would only be a minor change.
cheers,
Jakob
Attachment:
pgpqfpNOnGfHO.pgp
Description: PGP signature
--
gloox-dev mailing list
to unsubscribe:
send a message with subject 'unsubscribe gloox-dev' to minimalist@xxxxxxxxxx