On 21 January 2015 at 07:29, Lance Stout <[email protected]> wrote:
> I recall Ralph once noted that many of the major XEPs were each the third > try at the concepts. So here's hoping for components v3 :) > > We can but hope. '114 "just about" does the job, '225 hasn't caught anyone's imagination it seems. I believe this is functionally identical to '225, but aligns with the internal models of servers more readily. In particular, I think I could implement this easily enough in Openfire, Prosody, and (if I had access) M-Link. On the component library side, I have less experience, and would welcome opinion. > > The motivation for using __xmpp-component as a "domain" name is unclear to > me, but I'm probably lacking the imagination at the moment to create the > enlightening example. (It also makes me want to reserve an actual domain > name for this use case like how we use bob.xmpp.org in XEP-0231, but that > is probably a bad idea.) > > > The problem here is that S2S streams mandate a "to" attribute; so I wanted something there. In addition, I wanted a simple early signal that this was intended as a subordinate component, rather than an inbound session. Since the host server "answers to" the component's domain, most other cases would be indistinguishable from loop errors. It's a hack, though, and you're quite right for zeroing in on it. I'd forgotten about bob.xmpp.org - I'd have probably gone that route (I went for a special label form instead, of course). > > Can a component establish S2S sessions with multiple host servers? This > might seem odd in the context of most existing component implementations, > but the proposed XEP is essentially allowing an XMPP server to act as a > connection manager for another server using S2S. So I can easily imagine > the "component" to be a true XMPP service (that could typically handle > multiple S2S sessions), and the "host" servers acting as connection > managers. Maybe an implementation note? > > You could certainly use this to "bridge" two sets of domains, or use it as a special-case link between two ordinary servers, too. But I don't think it's special in this; the only thing preventing '114 from acting this way is that it's restricted to a single domain, and '225 will do this now. > > Can a component create or accept S2S sessions to non-host servers? I would > expect the answer to be no (what's the point of having the host server > then?), but it isn't called out. > > I don't see why it couldn't, and I certainly don't see why it would need to be prevented. > > > Overall, I like the idea. I also would be very interested in any attempts > (or past ones) to define things in reverse: connection managers that can > sit in front of any traditional XMPP server, and thus any S2S-style > component, implementation. > > I think once you consider "component connections" as simply an alternate form of S2S, then the obvious case is Isode's M-Link Edge product which does this "for a living". Actually this relates to the thing that interests me most about re-interpreting components as a server-to-server case - I think some really interesting use-cases become much more immediately obvious and understandable. We've tended to fall into a sort of cognitive trap of seeing components as "special clients" bound to a particular host server, whereas I think it's quite helpful to consider them as "special servers" instead. For one thing, any sentence beginning "you could have a component that" more easily becomes "you could have a remote service that". > > > — Lance
