Spark is already doing non-standard things.
Well, that’'s a bad idea.
chuckle Tell Jive that. (that said, the non-standard thing it wants to do in relation to the plugin is something they were talking about pushing towards an XEP)
Point me to where it says the standard says that the items response should be changed based on the requesting client.
Section 6.3 of XEP-0030 says that it’'s possible. The idea behind XMPP is to push complexity to the server, not the client.
Cool, I’‘d never seen that section before, but I still don’'t understand logistically how this would work. (see below)
Also point me to another server that does -not- implement it like this.
I’'m not familiar with the way this is implemented in any servers.
I’‘ve been writing non-Openfire related plugins for many years now and all of them do a disco inquiry the first time the transport connects and then store those results. I think it’'s primarily after the #info list so that it can easily pass on the features/etc of the entities to the client. (but they all seem to ask for #items too)
The whole concept has frustrated me for a long time. I’'ve always wanted the ability to filter/adjust the disco response based on the calling user and the option is just never provided to me. (unless the client -specifically- specifies the transport jid in disco. ie if you do a query to example.jabber.org, the request goes to the server and it answers on behalf of the transports. if you do a query to aim.example.jabber.org the transport itself really does get the opportunity to filter because the query goes directly do it)
It would be horribly inefficient for the server to re-request an items list every time someone did a service discovery.
The server does that for every disco to any client, and that’‘s ok? It’‘s even less of an issue with a plugin like yours, since there’'s not network traffic involved, just some local method calls. Even regular gateways are usually on the local machine.
The server does that between the client and itself. The server does not go “hey 83 components that are connected to me, can you tell me again who you are and what you do?”.
Besides that I’'m not forcing any clients to do anything.
Yeah, just like Microsoft isn’'t forcing anyone to write IE6-compatible web sites.
Just like no one is forcing XEP-XXXX on anyone but it’‘s there. There’‘s a lot of XEPs out there that aren’'t required. Course very little is really required in the land of XEP…
Clients that work like Psi won’'t care/need to do anything with it. (that have a service discovery browser instead of little individual icons like this)
It would still display useless information in the browser.
It already does. If you don’‘t support avatars, then jabber:iq:avatar is useless information displayed to the browser. If you don’'t support jingle then all of the jingle hooha is useless.
If it turned out to be a good idea, it could be proposed as an XEP.
That probably wouldn’‘t be accepted, since it’'s against the spirit of XMPP.
It’‘s really like the same as any other disco response. I do see your point about it pushing the complexity to the client though. Like I said though, I can easily filter if the query is made to the transport itself from the client. That’‘s easy. But that’'s not how things work.
If you’‘ve got better suggestions I’'m all ears.