I know that the use of a mail server has been mentioned a few times, but that isn't the type of model we want to employ. Maybe there was some misunderstanding on what my implementation goals are. My current model implements a single jabberd 1.4.3 client that manages it's own queue to compensate for the immediate delivery mechanism of jabber. The "big" little client, as I like to call it, just does too much -- it both queues and processes. Ideally, I want to have a bunch of jabberd clients (all performing the same processing, dedicated only to processing, but totally independent of each other). These clients should all be connected to a central message server that has logic to queue messages destined only for these available clients, and to forward a message only if an available client asks for one. I don't want to lose the immediate delivery mechanism that jabber supports-- my clients all have the need be be able to deliver asynchronous messages in near real time back to a message source -- but I need the server to be able to manage the incoming delivery of messages to these specific clients.
I think my current frustration with jabber is based on what I thought it could do out of the box. It does not apparently behave like a true MOM, and in order to get it act like so, would require some real dedicated customization. While it does support store & forward, it comes with a huge *BUT* -- but only for "offline" messages. At this point, the only way to effectively use jabber as an MOM in the type of model I wish to employ is to implement a component (as Mr. Millard suggests), which could manage the queuing, load balancing, & all that custom message request/forward stuff my scalable clients need. Thanks again for your comments. They have all been extremely helpful and informative. "Peter Millard" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Peter Saint-Andre wrote: > > The whole point of Jabber is decidedly *not* store-and-forward, it is > > immediate delivery. If you need POP, maybe implement all this using a > > mail server. > > You may also be able to get what you want by using a pubsub mechanism. See > JEP-60: > http://www.jabber.org/jeps/jep-0060.html > I agree with stpeter though, jabber is designed for near-real-time delivery. If > this doesn't fit your model, then maybe using something like an email server > would work better. Also, if you _always_ have at least one client connected, > offline messages would never exist. You also can comment out mod_offline in your > config file to turn off store-and-forward. This would mean that if a "client" is > not connected, then the message would bounce. > > You could also write a component which JUST does the load-balancing stuff and > does it's own store-and-forward... so when one of your custom clients comes > online, it could either use JEP-013 or some custom protocol to fetch the > messages currently stored in that component. This component could also be > responsible for doing the round-robing load-balancing instead of relying on > priority changes. > > There are always lots of ways to solve the problem. > > pgm. _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
