[jdev] Re: Re: architecture questions

[Joanne]

> > 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.