-
debacle
Can 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?
-
debacle
jonas’ I added it to the roster with JID = mycomponent.myserver.com.
-
jonas’
fun
-
jonas’
no idea then
-
debacle
In Gajim it appears under "Transports" then, which seems to be correct.
-
Kev
Gajim is almost certainly doing what most clients do, and starting with a disco#items on your server's JID, and then walking those.
-
Kev
I don't know, but that's the usual thing to do.
-
Kev
So if your component isn't listed in your server's disco#items, that might be an explanation.
-
debacle
Kev, I am not on that server, though.
-
debacle
Gajim asks my own server, but not that remote component.
-
debacle
To make things more fun: remote server name == remote component name.
-
debacle
But that is the same with Cheogram, which is also on a remote server and (if I'm not mistaken) has server name == component name.
-
Kev
I guess things to look for then are subscription state, and whether either of the other transports is using caps.
-
flow
I 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
-
flow
I'd expect there to be a generic implementation-independent mechanism
-
Kev
It'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).
-
flow
which 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
-
flow
is there none because we do not need one, or nobody bothered to write something down?
-
jonas’
we don’t need one
-
jonas’
(IMO)
-
jonas’
server config is fine
-
flow
I think debacle just demonstrated that one mechanism would be nice to have
-
flow
users/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
-
flow
well, 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
-
flow
jonas’, I don't think so
-
jonas’
how’s biboumi knowing which domains to add itself to disco#items wise?
-
flow
I 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
-
flow
well, per default probably to all vhosts of the server
-
jonas’
is that a server-side default or a component-side default?
-
flow
I don't argue that there are cases where manual configuration may be needed, but there could be sensible defaults
-
flow
probably server-side default
-
jonas’
prosody already adds components which share the same domain suffix to a vhost
-
Kev
I 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’
Kev, indeed
-
jonas’
but it seemed more like a protocol suggestion to me
-
Kev
It 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 :)
-
flow
Kev, 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
-
flow
but that is outside of the scope of xep114 obviously
-
flow
and a hint about a typical action you want to perform when using a xep sure is sensible
-
flow
however that action has to be performed (manual changes to the server configuration, automatically via stanardized protocol)
-
Kev
Would it be "allowing components to add " in that case, or "allowing authorised entities to add "?
-
MattJ
e.g. the admin, by editing a config file
-
flow
Kev, good question, probably "allowing authorised entities"
-
Kev
I 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"? :)
-
Zash
Admin ad-hoc command for adding disco items?
-
debacle
Kev, 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.
-
flow
debacle, I am curious: why did you subscribe to your components presence in the first place?
-
debacle
flow 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.
-
debacle
I believe, that the component also appears in Gajim under Transport, if I do not subsribe, but send/receive something over that transport.✎ -
debacle
I believe, that the component also appears in Gajim under Transports, if I do not subsribe, but send/receive something over that transport. ✏