IMHO, I would use Jabber. There's A LOT of Jabber APIs for every kind of language, and they all seem quite simple to be used. In case anyone asks: yes, it's purpose goes beyond instant messaging. And if you're feeling smart, it's very easy to modify the messaging system to implement nice features such as cryptography, etc.
-- Julio C. Ody http://rootshell.be/~julioody -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/SS/CC d@ s: a? C++(+++) ULB+++$ P++++ L+++$ !E W++(+++) N+ !o K- !w O- M V- PS+ PE Y+ PGP++(-) t 5 X R+ tv-- b++ DI-- D+ G++ e h r+ y++* ------END GEEK CODE BLOCK------ On Tue, 21 Sep 2004 16:09:34 +1000, Andrew Cowie <[EMAIL PROTECTED]> wrote: > Quick survey: I'm building something that requires a lot of two-way > (message/event) traffic between clients and servers, and could use some > help picking a technology. > > The server->client direction is tricky in conventional web (and web- > derived) models because it's always client request server response on > the clients schedule (no good for passing messages from server to > client, at least, not without client polling type behaviour, yuk). XML- > RPC would have been perfect except for that. Given how absurdly simple > and clean the Java APIs are, I may use it anyway. > > Someone at SAGE-AU suggested I consider ICE (an next gen CORBA, see > http://www.zeroc.com/ ). It's pretty impressive, but seems like an awful > lot of framework for what I would have hoped would have been a simple > implementation, especially considering that I view the problem in > message passing terms, not remote procedure calls or remote object > invocation terms. That said, the scalability, availability, and just- > works factor (once implemented) is alluring. > > In the Java world, there are obviously lots of frameworks, (ranging from > J2EE EJB containers down to small things like picocontainer) but I don't > really want a container at all - managing lots of objects, and > persistence, isn't the problem I'm trying to fight. > > Further, I'd like the server to be a relatively stand alone thing, and > containers introduce pretty massive installation headaches. OpenJMS > would be good in theory, but it's very heavily J2EE based, and brings > all that baggage. > > Any suggestions welcome. > > AfC > Sydney > > -- > Andrew Frederick Cowie > > OPERATIONAL DYNAMICS > Operations Consultants and Infrastructure Engineers > > http://www.operationaldynamics.com/ > > > > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > > > > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
