I guess this would end up being up to the server implementation, but right now resource -> priority handling could cause some problems here if you treated it just like a client. The idea here is to distribute the load amongst multiple instances of the external component. With clients, the higher priority would be getting all of the pubsub.example.org packets, and seeing as we don't have priorities here, would end up falling into the semi-confusion of "what to do with the same priority". So what do you go with, last one that connected? First one that connected? Last one that was active? In this case that's a little useless ... effectively we'd need round robin or something along those lines. But ... I suppose that boils down to "up to the server to decide on that". Are there any guidelines anywhere that even help decide what one should do if implementing this for clients or is it completely up to the server to decide how this works? 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. Just brain dumping some thoughts. I'm a little loopy from Sudafed (real Sudafed, not that PE crap) right now so bear with me. ;)
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? Daniel ----- "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: > Ralph Meijer wrote: > > On Thu, 2008-02-07 at 10:21 -0700, Peter Saint-Andre wrote: > >> Ralph Meijer wrote: > >>> On Wed, 2008-01-30 at 17:23 -0700, Peter Saint-Andre wrote: > >>>> If this is a second instance, the server could return an > indication of > >>>> that fact using something like a resource: > >>>> > >>>> <iq id='bind_1' type='result'> > >>>> <bind xmlns='urn:xmpp:tmp:component'> > >>>> <hostname>chat.example.com</hostname> > >>>> <instance>8ba991jag</instance> > >>>> </bind> > >>>> </iq> > >>> Huh, what? Why not be consistent and reuse the concept of > resources? > >> It seems to me that you would end up with things like this: > >> > >> pubsub.example.com/8ba991jag > >> pubsub.example.org/5fe372brd > >> pubsub.example.org/3bc716ffo > >> > >> Would those be routable addresses? If so, would they be routable > only > >> within the server (like the old <route/> packets in jabberd 1.x) or > also > >> from the outside? > > > > In general I would say that they should only be reachable from > within > > the thing you could call their containing server. This is kind of > vague > > and that's ok. It is mostly an implementation detail and local > security > > policy what you want to be reachable from the outside, IMO. > > Sure, we leave that up to the local service policy. :) > > OK, I will work this into the next version of the spec. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/
