On Sun, Nov 06, 2005 at 01:56:02AM +0100, Jakob Schroeter wrote: > > > 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. In my particular case, the client will be making no changes to the roster. It is only interested in getting the group lists and status changes from the server. Put differently, it does not use synchronize(). I'm really just using the Client's RosterManager so that I can tell what groups users are in. Otherwise, I'd probably be implementing handlePresence instead. With the insight that you have provided above, it is time for me to go reread the docs. I am new to XMPP/Jabber, and so some of the concepts involved are new to me. Things such as "roster-push", which you clear up a bit above. Is the invocation of the RosterListener::Roster() method the result of a "roster-pull"? It appears to be the result of a query that was made by the RosterManager. > > 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. So itemChanged refers to any item change, whether it is done locally or caused by the server, and itemUpdated only refers to changes done by the server. Is that correct? In that case, will I get both itemUpdated and itemChanged events for changes that came from the server? If I get both, can I count on one of them (probably itemUpdated, since the update causes the change) arriving before the other? Will an itemUpdated always be followed by an itemChanged with the same information? > > > 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. Oh, I'm full of questions. 8) > > 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. I have managed to reproduce the behaviour that I was talking about before, and your patch does, indeed, produce the desired result. While you're revamping stuff, I have an issue with the debugging output. I am coping with it by configuring the build with --without-debug and supplying my own handleLog method. The particular issue is that debugging goes to standard output, and my program needs to control that. It was causing mysterious failures until I figured out what was going on. The debug output was getting written directly to a piece of hardware that wasn't expecting it. Debugging output is fine, and often quite helpful, but an application linked with the library shouldn't be spewing bunches of output by default no matter how used to that we may have gotten by running KDE apps. I think debugging should be settable at runtime, and if it is set, it should log to an (i)ostream which was specified when it was turned on, or cerr if it wasn't specified. --without-debug could still be used to prevent compilation of the debugging code for production installs of the library (or not) as the admin/packager chooses. Having debugging enabled at runtime enables a library with debugging enabled to be installed on the system without generating debug output unless the application using the library actually wants it. This is just my opinion. As for how to turn debugging on, everything that wants to debug would have to look at some object, whether it is the Client, the Connection, or some object that exists solely for this purpose. And you'd turn debugging on in a method of that object. -- gloox-dev mailing list to unsubscribe: send a message with subject 'unsubscribe gloox-dev' to minimalist@xxxxxxxxxx