On Fri, 2004-02-20 at 12:55, Joanne wrote: > "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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 _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
