2011/8/16 Jehan Pagès <[email protected]>: > Hi, > > so I have just implemented something with XEP-0114 (client side) and I > have a few questions. > > (1) In my case, the component was locale. And I imagine that's quite > the most common case. But that's definitely not an obligation > (especially as we could imagine "component service providers"). Hence > TLS encryption should be possible. > > Maybe it is, but XEP-0114, definitely tells nothing about it. It looks > like the way-to-do is connecting and directly handshake in plain text. > Maybe a <features/> logics would be nice. It would allow TLS, compression, > etc. > This could be added in the same time we pass to an SASL authentication > for component.
Correct. We have been aware of these issues for some time. That's why XEP-0225: Component Connections exists. XEP-0225 is the way forward. However, there aren't many implementations. I suspect the reason is that XEP-0114 is good enough for most. Most component deployments are on the same machine as the XMPP server, and using TLS or compression in that case is rather pointless. We plan to add support for this to Prosody soon. It can enable all sorts of interesting features not currently available to components. > (2) Is there not any default port (xmpp-component) for components, > same as we have default ports for xmpp-client and xmpp-server? > Or do we consider it the same as the "secret", which is that anyway > every component is expected to use a different port, that is known > only by configuration? > Note that this point does not annoy me. After all, components are > specific configured items (and usually limited) so we can consider the > port as a "configuration-only" information. Nevertheless a text about > this point may be worth added in the XEP to better explain the logics. > Also I think a server implementation should allow for multiple > components on a single port (I did not test if they already do this. I > just say we should add the text). If your server has 20 components, > you might prefer not to have to each time you add a component, open a > new port, but simply use the same as for your other components. Some older servers in fact require that each component be on a separate port. XEP-0225 solves this too. We just need to get everyone to start using it :) > (3) The current logics seems to be that the component connects as > component.shakespeare.lit, keeps a long-live connection and from there > sends stanzas as [localpart@]component.shakespeare.lit[/resource] and > process any message sent to such an address. > That makes sense in this very common connection logics. > > Now I have a use case where I would like to be able my component to > connect as different "entities" on this component. Basically I cannot > make a long-live connection. So I just want to be able to connect > several times. > For instance the component could connect as: > <stream:stream > xmlns='jabber:component:accept' > xmlns:stream='http://etherx.jabber.org/streams' > to='plays.shakespeare.lit/someresource'> > > Or it could be also with a localpart (basically any JID that the > component plays.shakespeare.lit has control on). > For this kind of use case, we would want routing rules. > Basically if I connect with component domain part only, I would want > to receive any stanza. But if there is a stanza sent to a given > resource, and if the component is connected with this resource > specifically, it would grab the priority to receive this stanza. On > the other hand, the component connected with a resource must not > receive any stanza if another precise resource is specified. > > And so on. Basically I propose to take into account this new kind of > component connection logics with routing rules (that we could now > discuss, or I could just propose the list of rules which I have in > mind). > That does not prevent the current usual logics: a single connection, > long-live, as the main component domain part. But that allows new > logics with multiple connections and appropriate routing. > What do you think of this? What's the use-case? And I'd like to see your proposed rules, particularly how it works when a component goes down. If it's load-balancing, the reason we don't have a standard is because there are multiple possible load balancing strategies, none of which is perfect. Prosody allows components which are "node@host" or "host/resource". I haven't verified if this works for external components, but we've used it to do a number of interesting things with internal components (e.g., MUC loaded on "[email protected]", with "example.com" being a normal host with user accounts). > Jehan > -- Waqas Hussain
