I get a 501 Not Implemented error, as one would expect.
Unfortunately this means I can’'t use
di.containsFeature("jabber:iq:search");
for example.
Other clients, such as Psi, know what features are supported and the category and type of the entity (Psi reports category=“service” type=“jud” and “jabber:iq:search” is supported for jud.localhost) even if it doesn’‘t directly support DISCO or the older jabber:iq:browse, and enable/disable buttons accordingly (which is what I’'m trying to do).
At the moment I can query localhost and jud.localhost shows up in the list as a “child”, but I can’'t implement the applicable logic for the action buttons (Register, Search, Join Room, etc.).
I don’‘t know what Psi is doing but if the server didn’‘t return that info your client shouldn’'t be able to know what “jud.localhost” means.
You can send a disco#items and get “jud.localhost” as a response. Maybe Psi is assuming that any returned item that starts with jud refers to a jabber user directory. You can try that approach but you should have in mind that it’'s not a legal/standard action.
Have you opened a debugger window using Psi and checked that in fact Psi is getting the same response from the server as Smack?
I checked the xml Psi was recieving, and it also recieves the 501 message (as SMACK correctly reports ).
Psi is probably doing what you suggested to make up for the defficiency in _jabberd1.4 (where you can “see” jud.localhost as an item of localhost but can’'t find out any info about it ).
Now, do I copy Psi’‘s hack in the interrest of end-user usability, or do stick to the standards?.. I think I’'ll have it has an option (and thus avoid having to make the decission myself )