Hi,
IMHO it is required for the ParticipantStatusListener’'s to not only get the affected JID, but also the Presence packet which lead to this change.
otherwise it is impossible to retrieve more information like the reason for a kick/ban/whatever …
and it makes it also possible to get the old nickname on a nicknameChanged ( #SMACK-55 )
cu
Herbert Poul
anyone want to comment on this ? tell me if i’'m right/wrong/dumb/whatever ?
shouldn’‘t be much work either to to this … something like … http://yourhell.com/~kahless/mypatch.txt would be enough … and you are sure that you won’'t need to change the api another time you see that information is missing (like… currently … the nickname change problem)
Hey Herbert,
Sorry for the late reply. The idea of ParticipantStatusListener is to provide a higher level API thus hiding the packets and raw XML layers. After reading your posts and checking with the JEP-45 spec I confirmed that we were also missing the reason and actor information in ParticipantStatusListener#kicked and ParticipantStatusListener#banned. I created SMACK-81 for this issue.
Thanks for pointing this out.
Regards,
– Gato
imho a higher level API shouldn’'t prevent xmpp from beeing extendable … since this is the whole idea about it … e.g. in non-anonymous rooms you will receive the full jid in the initial presence packet …
if you don’‘t want to change this in ParticipantStatusListener it would be nice to make some sort of workaround … since there is currently no simple way … (except … copying the whole code of the MUC packet listener… which i don’'t think is simple…)
maybe you could add some sort of ParticipantStatusPacketListener which has only 1 method with the parameters String (the name of the method which will be called in the ParticipantStatusListener) and the actual Presence packet … this shouldn’'t be too much work either …
anyway … thx for looking into it
Herbert Poul