Ad hoc commands problem

Openfire Openfire Dev
1

Hi, I think I found a little problem in the ad hoc commands implementation. When I send the command get-active-users I get this result:

2

I the first post the xml was deleted. I repost

Hi, I think I found a little problem in the ad hoc commands implementation. When I send the command get-active-users I get this result:

<iq from=“dalek” type=“result” id=“ab07a” to=“ff@dalek/dalek” ><command xmlns=“http://jabber.org/protocol/commands” status=“completed” node=“http://jabber.org/protocol/admin#get-active-users” sessionid=“2isTM2kT7763WNT” ><x xmlns=“jabber:x:data” type=“result” ><field type=“hidden” var=“FORM_TYPE” ><value>http://jabber.org/protocol/admin<field type=“jid-single” label=“The list of active users” var=“activeuserjids” ><value>ff@dalek</value><value>testthree@dalek</value&g t;<value>testone@dalek</value><value>testtwo@dalek</value&g t;</field></x></command></iq>

Here there are at least two errors:

  • the jid-single field with multiple values

  • the <item/> tag should be used for correctly reporting the different values, one for each <item/>; in such way, with also the help of the <reported/> tag describing the headings, the client can display a tabular result

bye

3

Hey Fabio,

Wildifire’'s implementation is based on XEP-133 example 74. There you can see that the answer should contain each JID as values of the same field. I agree with you that using a report data would have been nicer but that is not what the specification says. May be you may want to post your suggested improvement to the XMPP mailing list.

Regards,

– Gato

4

I wasn’‘t aware of JEP 133. The fact is that the examples are in contrast with JEP 04 and none of the clients I’'m using is displaying correct results. I will bring this issue to the XMPP ml.

BTW, which client are you using for testing these commands?

Bye, FF

5

Ciao Fabio,

I was using Exodus and Psi for testing them. However, as you mentioned, clients are not always rendering the results correctly so I was verifying the correctness of the XML using the console debugger.

Regards,

– Gato

6

Well, I’‘m going to discuss this issue in the xmpp ML, but it appears that the clients are rendering well, it’'s the specification that is broken. From JEP-04:

<value/> – The XML character data of

this element defines the default value for the field (according to the

form-processing entity), the data provided by a form-submitting entity,

or a data result. In data forms of type “form”, if the form-processing

entity provides a default value via the <value/> element, then

the form-submitting entity SHOULD NOT attempt to enforce a different

default value (although it MAY do so to respect user preferences or

anticipate expected user input). Fields of type list-multi, jid-multi,

text-multi, and hidden MAY contain more than one <value/>

element; all other field types MUST NOT contain more than one

<value/> element.

bye, ff

7

Got an answer from psa on the standards ML. First of all he acknowledges that the examples in XEP 133 aren’‘t clean and that fields type should be made explicit. He says that that field is text-multi, indeed, looking at “field standardization” in the bottom, we discover that it is jid-multi. In any case it’'s not text-single, since no client compliant with XEP-0004 could render it correctly.

bye, ff