Hi Iain, First of all congrats for writing for what seems to be a good book that fills a void in the market (I had a look at the table of contents). I couldn't help oberving that your book concentrates more on the server and very little information on java clients seem to be given. Most java developers want to make use of instant messaging facilities, and not build them from scratch. Especially when there are open-source, free, stable, mature and multi-platform implementations already available (the jabberd server) What java really needs is a good java client library for Jabber. The JabberBeans project at sourceforge seems to have fizzled out. In my opinion because it tried to do too many things - satisfying both client and server needs and becoming bloated and bug-ridden in the process. Does your book cover building java clients/ client libraries ? Thank you, Tarun
Hi, Thanks for the kind words and great comments. My book develops a client library focused on testing the Java Jabber server developed throughout the book. I agree that there is a strong need for a Java Jabber library that is clean, small, and focused. Due to the intent of the book's client code (server testing) it doesn't meet these requirements. As you point out the JabberBeans code tries to do a lot and has not seen much active development these days. My book's client code is nice in that the code is small and simple so is easier to understand. However, it is code developed for teaching/reading so it leaves out the normal error checking and handling that you'd want in production code. Honestly, I think a fresh start would be best. If you were to start an open source project (like on sourceforge) I think you'd have quite a few people that would help. In my opinion, rather than using SAX parsing as is done in my book, I think JDOM is the way to go for a client library. In addition, a basic framework for Jabber packet handling with plug-ins for each protocol would make the library easier to use and configure for any particular problem. My book code uses this basic design and could serve as a model for doing this. However, I'd probably use a standard plug-in standard like Java Servlets rather than my book's ad hoc method (the book code tries to avoid too many external library dependencies so there's quite a few areas where it can be improved simply by using the logical standard technology rather than my simpler, and less capable custom code). Whew. So if you're still with me, I agree with you. We need such a library and it doesn't really exist today. Hopefully someone will seize the opportunity! -iain
thought you might be interested to know that there is a java jabber library being developed. it doesn't look complete, but maybe some ranchers out there can lend a hand to help write the library. http://www.jabberstudio.org/projects/view.php?id=2 [ June 19, 2002: Message edited by: Jon Dornback ]
use the [CODE] tags - it makes it much easier for people to help you.
In my opinion, rather than using SAX parsing as is done in my book, I think JDOM is the way to go for a client library.
Could you elaborate more on this please. Is it because JDOM is simpler ? I thought that SAX would be better for streaming xml type applications. What are your reasons for wanting to choose JDOM over SAX ?
In addition, a basic framework for Jabber packet handling with plug-ins for each protocol would make the library easier to use and configure for any particular problem. -iain
I guess this is the server that you are talking about. Does the jabber client need to know anything about the implementations of different messaging protocols like MSN, Yahoo, etc ? I mean is the jabber im system totally transparent, or is there some work to be done at the client side ? I am yet to read the jabber docs fully so do excuse me if my questions are a bit naive. Thank you, Tarun
It looks a pretty low level library. But thanks, I didn't know it existed. I guess what we need to do is to build a proper full-fledged client-library over it.
Originally posted by Jon Dornback: thought you might be interested to know that there is a java jabber library being developed. it doesn't look complete, but maybe some ranchers out there can lend a hand to help write the library. http://www.jabberstudio.org/projects/view.php?id=2 [ June 19, 2002: Message edited by: Jon Dornback ]
Originally posted by Jon Dornback: thought you might be interested to know that there is a java jabber library being developed. it doesn't look complete, but maybe some ranchers out there can lend a hand to help write the library.
Cool. Hopefully we will see some more development in client libraries. -iain
JDOM vs SAX For servers SAX is probably the way to go as it is fast and efficient. However, clients will be network or user bound (waiting for i/o) so the efficiency of parsing and representing data isn't very critical. In this case, developer efficiency rules. If you haven't already, take a look at JDOM (www.jdom.org i think). It's basically DOM customized for Java so you can do stronger type checking and it follows Java library conventions for collections, iterators, etc. making it easier for most Java developers to use. In the Jabber protocols you will be sending and receiving XML 'packets' which are sub-documents of the larger XML stream document. Each component in the client will handle each of these XML packets as relatively independent data. It is handy to develop clients with an event architecture with the XML packets serving as events. This plugs in well with the Swing event model too. When you use SAX your events are the individual, low level XML information such as start tag, end tag, character data, etc. In most cases, you will end up building a class or data structure which is very tree like. In servers it is worthwhile to go through all sorts of contortions to make these XML packet objects as efficient as possible (sharing strings to reduce object churn, optimizing building and recycling of these objects, etc). On the client, this isn't such a big deal so you might as well let JDOM build you a generic JDOM document and use that as your packet object. This doesn't eliminate the need for "framing" up these sub-documents so the XML parser (JDOM or SAX) treats them like separate documents. This takes customization of either the stream feeding the parser, the parser itself, or the JDOM document builder (or your own custom object builder class). If you read my book, you'll see how I did it with SAX, custom object builder classes, and custom packet objects. If I were writing a client library, I'd probably use a pull-parser like the embedded pull parser from www.enhydra.org, and design a custom JDOM builder class. Basically, my argument for using JDOM is laziness (i.e. lazy as a programmer virtue... see Perl, or old unix programming books for why this is such a great thing). Being lazy in the right ways usually leads to better libraries. Jabber clients and foreign protocols In general, Jabber clients don't need to do anything to support foreign protocols like AIM. Bridging to these networks and translating data formats are jobs performed by the server in most cases. However, some systems like AIM have been blacklisting Jabber servers by watching how many users are logged in from a single IP address and blocking those that exceed some limit (a good sign that a Jabber server is at work). So some client authors have been writing their clients to hande foreign IM systems. However, AIM has been pretty good at doing things like asking for message digests of their client's DLLs and other things to make sure that you're only accessing AIM through AOLs client. It's kind of a losing battle unless you really want to devote a lot of time to fighting AOL. Most other systems though tolerate some bridging and for those, there is usually Jabber server support (Yahoo for example). And truly open systems have excellent Jabber server support (IRC for example). -iain
If you live in a cold climate and on the grid, incandescent light can use less energy than LED. Tiny ad: