[jdev] Re: architecture questions

[Peter Saint-Andre]

On Fri, 2004-02-20 at 12:55, Joanne wrote:
> "Peter Saint-Andre" <stpeter at jabber.org> wrote in message news:20040220184924.GA23167 at jabber.org...
> > On Fri, Feb 20, 2004 at 10:30:59AM -0800, Joanne wrote:
> > 
> > Hi Joanne,It's good to see folks from Jambotech on the list -- I recall
> > some involvement from people there a few years ago. BTW, coding
> > questions belong on this list, not JADMIN (that's for server
> > administration), so no need to cross-post.
> > 
> > > (1) message queuing/processing
> > > It seems that jabber's queuing mechanism is only dependent on a a client's "online" status. If a client is offline, jabber will automatically queue the messages in an offline store. But as soon as the client's online presence is detected, jabber will start "pushing" all queued messages to it automatically. Assuming our jabber client had no queuing mechanism, we would have to block while processing each message. Would this block->process type of method work well within the jabber framework in order to take advantage of its built in queuing mechanism? I wrote a simple client to test this type of processing and on the surface it appears to work, but I was just wondering if anyone might see other factors/issues/caveats I might not be considering before I choose this type of implementation.
> > 
> > First, you may be confusing "Jabber" wiht specific implementations. Most
> > server implementations will do offline queueing as you describe,
> > but that's a matter of implementation and configuration. Also, the
> > message flood that you refer to on login can be addressed with the
> > protocol defined in JEP-0013.
> 
> We're specifically using jabberd 1.4.3 as provided from the jabber.org site with no modifications. Based on this implementation, it appears the offline queueing is active by default. I also took a look at JEP-0013 yesterday, but is that something that is supported out of the box? I guess I'm a little confused about what JEPs actually represent. Ideally, it appears to have solved my message "flooding" concerns, but how can I configure jabberd to operate according to this protocol. Also, are there any issues with just blocking on my message processing loop so that I don't handle any incoming messages before finishing the message I'm currently processing? If I can implement this, the message flooding becomes a non-issue, right? 

AFAIK, neither jabberd 1.4.3 nor jabberd2.0 support JEP-0013 yet. But
jabberd2.0 will do so before jabberd 1.4.3 (if the latter ever does).

JEPs are specifications published and in some cases approved within the
Jabber standards process: <http://www.jabber.org/jeps/>. Everything in
the Jabber world revolves around the protocols we use.

> > I probably missed your previous messages to the list -- what kind of
> > application are you trying to write?
> 
> 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