> > but > > right now resource -> priority handling could cause some problems > > here if you treated it just like a client. > > Who said anything about priorities? That's a presence concept, not a > resource binding concept.
Hehehe I wasn't meaning to say -this- would involve priorities, I was just saying that's generally involved in how bare jid packets are routed for client sessions, and that we don't have said concept here. > > It might be nice, at least here, to have some > > strict rules. "Bare JID references will be round robin" or > something > > like that. I suppose the setup could be part of the local security > > policy as well --- let the server admin decide. Of course that > > doesn't help if one external component expects the server to work > one > > way, and one expects it to work a different way. Hell, it may even > > be something that needs to be configured server side to work, > > "period". Of course, that's more confusion on the part of the > server > > administrator -- more steps to have to run through. > > Life is hard. If you want to run a highly-scalable service with > clustering and round-robin components and all that, you have to > expect > the effort to involve some brain-damage. And if you don't want the > brain-damage, don't get into the business of hosting highly-scalable > XMPP services. LOL Yeah, good point. I imagine if one wanted to make it easier for specific scenarios, one could build the logic into their own server implementation or plugin or something like that. Still, there was a point when we were thinking through this in terms of, the component itself tells the server "I'd like to allow other components to use this as well". Could also determine the routing logic -but- ... the more I think about it, it really does make sense to have the server administrator/server itself set this up. Gives the administrator defacto control over what can and can not be done. > > Anyway, am I reading this right as resources seem to be the way to > > go, even if it might require some folk to rethink how they're > > using/referencing components? > > Yes, I think XEP-0225 will require a significant rethink of component > handling in certain implementations. But the idea is that the rethink > will be worth the effort since the new approach will be more flexible > etc. So so we hope. :) Indeed! I'm pleased to see we're able to rethink some things with transports now that they're starting to branch out from more than just IM gateways. Are you planning on doing a draft about these concepts that I should keep an eye out for? ;D Daniel
