Hi Matthew, On Tue, Apr 2, 2013 at 2:00 AM, Matthew Wild <[email protected]> wrote: > No, you're right, this seems like an issue. XEP-0033 is an old one, > and though I'm barely old enough to remember it, the original jabberd > server was essentially a collection of components. Since they were all > part of the server, they were ultimately trusted. XEP-0114 and the > concept of 'external' components grew from this, but obviously the > level of trust was diminished.
Thank you for the historical insight ! > I mention this because perhaps it's worth relaxing that MUST in > XEP-0114 at least to a 'SHOULD' or 'OUGHT TO'[1]. We kept the ability > in Prosody to allow things like external XEP-0033 to be possible if > the server admin so wished, and it seems it isn't the only > implementation doing so. Ah, great ! I am using Prosody at the moment, will see how to change that setting. > On the other hand, I think external XEP-0033 is a little uncommon. > Part of the reason for it is efficiency on the wire, it makes sense > for the server to be able to handle it directly and emit stanzas, > instead of going through the overhead of passing them out to a > component and then being bombarded with the resulting stanzas. I consider the functionality in XEP-0033 (ie, one-to-many message sending) as something that should be the core of an IM system, so I'd like to build a component that can be used by all the XMPP servers willing to implement that functionality. All they'd need to do is implement XEP-0114. Instead of writing yet another plugin for yet another server (and, even before that, hoping that this new server has some plugin functionality), you could stick to XEP-0114 and get the functionality "for free". Plus, XEPs are reviewed by far more people and go through a far more thorough process before being accepted as standards, so you can expect more documentation on this side than on any server's hypothetical extensibility. Now, it will add overhead, but I think this would start to harm the server only when you have a lot of communication going on. This can easily be the case with regard to how XMPP is built today, where all shared communication is centralized on one single host; however, I think that scheme is bound to be changed, because it won't hold the load: there needs to be something to delegate part of the job to other servers. I see there are some interesting developments in that direction (I'm thinking about XEP-0289[0], for example), and I think this will relieve servers much more than optimizing the inter-process communication between a server and its components. But I'm only speculating here, I don't have any real experience. > That said, I don't know your use-case and perhaps you won't have as > many recipients as I'm fearing :) Ha, thanks for reminding me I don't have many friends :) Regards, -- Matthieu RAKOTOJAONA [0]: http://xmpp.org/extensions/xep-0289.html
