Hi, On May 29, 2007, at 11:22 AM, Norman Rasmussen wrote:
> On 5/29/07, Pedro Melo <[EMAIL PROTECTED]> wrote: >> Basically, ejabberd does not have the features required to use >> compjid, but it does have a module (in SVN) to do domain balancing. > > domain balancing looks great, as long as there's a way (bare_source + > component_number looks fairly close) to make sure that the same user > _ALWAYS_ uses the same component instance. bare_jid and domain_balancing_component_number is the set we use. It's good enough. it's not perfect. If two transports die at the same time they might get a different component_number but only between the two that died, so the damage is local to those two. You could work around that if you use the compjid to set the component_number, but the domain balancing code would be more complex. So far I was not able to convince Mickael that it is a good trade off :).. Granted, I really don't think we *really* need perfect match. In the case of multiple dying transports, only users on the affected transports will suffer anyway. > There is a item on the TODO list to support non-bdb backends for irc > and yahoo transports. Something like the xml backend used by the > other transports, or even sql backends (like mysql or postgres) This is an interesting issue, the backends. In the recent months, I've taken a different approach: support a single backend - HTTP- based REST webservices. They are easily plugged in into the async nature of transports, and they give you an abstraction layer that can make your transports accept any kind of backend, SQL or not. Best regards, -- HIId: Pedro Melo SMTP: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED] _______________________________________________ py-transports mailing list [email protected] http://lists.modevia.com/cgi-bin/mailman/listinfo/py-transports
