debacleCan someone enlighten me in respect to disco, please? I hacked together a component. My client, Gajim, does not perform a disco "get" to that component, when connected. It does so, however, with other components, such as Biboumi or Cheogram. I assume, I'm missing something in the protocol, so that my component is considered worthwhile by Gajim to perform a "get". But what would that be?
jonas’debacle, how does gajim learn about your component?
debaclejonas’ I added it to the roster with JID = mycomponent.myserver.com.
jonas’no idea then
debacleIn Gajim it appears under "Transports" then, which seems to be correct.
KevGajim is almost certainly doing what most clients do, and starting with a disco#items on your server's JID, and then walking those.
KevI don't know, but that's the usual thing to do.
KevSo if your component isn't listed in your server's disco#items, that might be an explanation.
debacleKev, I am not on that server, though.
debacleGajim asks my own server, but not that remote component.
debacleTo make things more fun: remote server name == remote component name.
debacleBut that is the same with Cheogram, which is also on a remote server and (if I'm not mistaken) has server name == component name.
KevI guess things to look for then are subscription state, and whether either of the other transports is using caps.
flowI always wondered about the mechanism which makes (external) components appear in the disco#items response. Is that documented/specified somewhere?
jonas’flow, in your server’s docs
flowI'd expect there to be a generic implementation-independent mechanism
KevIt's entirely down to your server. I keep getting tempted for M-Link to make it able to list arbitrary entries in its disco#items (so if there are common remote MUC services, it could list those for discoverability, for example).
flowwhich is maybe coupled to the external components protocol
jonas’flow, there isn’t
jonas’Kev, prosody has that, fwiw
jonas’it’s useful because my HTTP upload service lives on a different domain which would typically not be associated with the user domains
flowis there none because we do not need one, or nobody bothered to write something down?
jonas’we don’t need one
jonas’server config is fine
flowI think debacle just demonstrated that one mechanism would be nice to have
flowusers/admin expect that their extenral component appears in clients once they configured it, not that an additional configuration step being required to do so
jonas’flow, I don’t think he did
jonas’flow, there would still be configuration required in any but the most trivial cases
flowwell, he wrote a component, was obviously be able to connect it with his server, but wondered why gajim did not discover it. AFAIKT the answer gajim did not discover it, is because it is not in the disco#items response
jonas’flow, you’d have to tell the component or the server for which domains to allow/attempt additions to disco#items
flowjonas’, I don't think so
jonas’how’s biboumi knowing which domains to add itself to disco#items wise?
flowI do not know biboumi, but the trival case is that component.example.org is added as item
jonas’to which domains?
jonas’my prosody has about five
jonas’plus about seven more component domains
flowwell, per default probably to all vhosts of the server
jonas’is that a server-side default or a component-side default?
flowI don't argue that there are cases where manual configuration may be needed, but there could be sensible defaults
flowprobably server-side default
jonas’prosody already adds components which share the same domain suffix to a vhost
KevI think that if Flow is proposing a line in XEP-0114 that says "You probably want to add this to your disco#items too" (if there isn't one - I've not looked), then it seems sensible enough to me.
jonas’but it seemed more like a protocol suggestion to me
KevIt wasn't clear to me, I'm skimming in and out. But I think that line would be sensible (if not present already), whether it was Flow's suggestion or not :)
flowKev, I am actually also propose a standardized protocol allowing components to add themselves to the disco#items of the server
jonas’agreed, though I’d probably suggest to limit it to vhosts which are a suffix of the components domain name
jonas’you wouldn’t want your various domain-specific MUC services to appear on all domains for example
flowbut that is outside of the scope of xep114 obviously
flowand a hint about a typical action you want to perform when using a xep sure is sensible
flowhowever that action has to be performed (manual changes to the server configuration, automatically via stanardized protocol)
KevWould it be "allowing components to add " in that case, or "allowing authorised entities to add "?
MattJe.g. the admin, by editing a config file
flowKev, good question, probably "allowing authorised entities"
KevI suspect this is one of those nice things whose value isn't great enough to be worth the effort, but I might just be being unimaginative.
Kev(We seem to have lasted this long with the current behaviour, although making that behaviour documented if it's not seems sensible to me)
flow> jonas’> agreed, though I’d probably suggest to limit it to vhosts which are a suffix of the components domain name
how about "add only under the one vhosts if the suffix matches, otherwise add to all vhosts"? :)
ZashAdmin ad-hoc command for adding disco items?
debacleKev, caps is a difference, indeed. Gajim sends disco get to the components with caps in the presence (or whatever it was), my component does not.
flowdebacle, I am curious: why did you subscribe to your components presence in the first place?
debacleflow I'm not sure why I did :-) I wanted to see the component, because it is not only a transport, but also offers an adhoc command.
debacleI believe, that the component also appears in Gajim under Transport, if I do not subsribe, but send/receive something over that transport.✎
debacleI believe, that the component also appears in Gajim under Transports, if I do not subsribe, but send/receive something over that transport. ✏