> > We're planning on implementing A2A communication between a java-based jabber > > client app that runs on our web server and a another server-side jabber client > > C/C++ app. So all interaction over the jabberd transport is strictly within our > > internal server network. We currently have a jabber client that has built-in > > message queueing abilities, but we have discovered reliability issues and > > difficulties in scalability. So we'd like to implement a more simplified client by > > removing its queue mechanism & extra threading, but this means offloading that > > process to jabberd -- which seems logical enough since it already has queueing > > capability. The only issue becomes controlling the flow of messages to client from > > the queue, which I can only do by blocking within my client's message event loop. > > It seems to me that a component would meet your needs more fully, built > with something like JSO: <http://jso.jabberstudio.org/>. > > Peter
My understanding of how a component differs from a client is a bit shady though. Why do you say it would be better? If my understanding is correct, components can't take advantage of the store&forward/queuing mechanisms in jabberd. If I go the component route, I would have to implement a queueing mechanism within it, right (which I'll have to do anyway for the load balancing stuff, but that forget that for now...)? Also, what if my component goes offline? I know with clients, you can have n+1 clients with the same jid & unique resource id and have jabber forward messages to it based on presence priority. Can this be done with components? I guess I can't clearly see what the difference is between component & client. _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
