writing client side totally in Java

[Nicholas Jordan]

Still struggling to get oriented on xml, reading rfc 3920 and 3921 { I work from rfc's where possible to get reference specs } I pretty much have adopted Java as the development language of choice for several reasons. Someone approached me about doing some work and I have chosen a simplified textual chat client as it is beginning to look like the server client chooses to use is a drop-in or already installed ( still becoming familiar with the specs )

I have an "I do it this way" style, everything in one massive file-scope. I just work in direct source code with powerful text editors.

No ide's no fancy tools, just raw 10-k copy-pastes or write it myself and hit the build button. I need to get oriented on xml and xmpp :: I have

http://www.faqs.org/rfcs/rfc3921.html
http://www.ietf.org/rfc/rfc3921.txt
http://www.xmpp.org/about/summary.shtml
http://java.sun.com/j2se/1.5.0/docs/api/overview-summary.html
http://java.sun.com/webservices/technologies/index.jsp#Core_Web_Services

open in browsers right now, found my way here by following links from the last url cited.

I will soon saturate, I need some pointers to basics on xml and xmpp == simple samples minus the verbosity. Sort of a KISS approach. The sort of page for the person who thinks he is a fast learner.

[Jehan]

First the official page about the current development of the protocol:
http://www.xmpp.org/
Though one of your link is from there, others are not and maybe there may be older versions. So I advice to look there as the best reference.

From there, you will have all the parts of the protocols, the most standards one for a client are the rfc 3920 and 3921. These 2 pages are the place where you have absolutely to begin before everything all:
http://www.xmpp.org/rfcs/
And to answer your request, these pages may look verbose, but they are not so difficult to read. Of course these kind of pages must not be read in details first! You must read very fastly (it is important to read technical stuffs fast to have a general glimpse of the structure and not getting drown in small points) using the table of contents so that you can get the basic idea of the structure of XMPP. This way the first time I got interested in XMPP, I read the 2 RFC in less than 30 minutes maybe and then I understood how Jabber was working.

From there, you will read precisely a few part (still using the table of contents!) you decide to consider for implementation. Except this recommandation, I know no good document to understand it (maybe it exists?).

Maybe I could write one someday. Nevertheless I can give you at least one hint so that you understand the functioning of XMPP. This is the most important part of your work and yet the faster to get (in fact this is known through the first step of rapid reading I proposed):

1/ First you have a separate part which is authentication. The whole authentication process is shared between the 2 RFC 3920/1 and the examples are really explicit. Just read them, you will understand soon.

2/ Then once authentication is done, you are simply in the normal run of XMPP! You have arrived in Jabber land, and everything is quiet here: nothing happens at first!

But still things can happen in this strange land and these things always implies 2 (and only 2!) entities, an entity being either a client (a person or a bot most of the time), a server, or a service. Of course your server is always implied in reality as it is the one routing stuffs for you, but this is only forwarding in most case -- and not participating -- so I don't count this (but some other cases, it can be one of the 2 participants). This is why an important part of all these things are the "to" (recipient) and "from" (sender).
And so these happening things (XMPP call them stanzas) are one of 3 possible things:

- a message: this is something which is sent from an entity to another but does not require any answer. Basically it will be what you call a message in "instant messaging", but it can be a notification, an information from some service, etc.

- a presence: this is simply a status message. This is used for information you display about yourself, whereas messages are information you intend to others (the former is about you, the latter is about others). This is of course used mostly for all presence stuffs, but extensions are possible.

- a query (IQ = Info/Query): as the name implies, it is used when you ask something to another entity! So at the opposite to the 2 other actions, you are awaiting an answer. Mostly you can ask 2 kinds of stuff: receive information (type="get") or propose information (type="set"). For instance, in the pubsub XEP, it is used to receive the items stored in an information tree or to store new information for other people to get them.
This kind of events is a lot used because it is the most flexible as it is really about exchanging stuffs. And in fact it is very generic and the 2 other events (message or presence) could be considered as IQ without any feedback.

So when an entity wants to say something to some other entity but don't care of the answer, it sends a message; when it wants to say something about itself and don't care about the response, it is a presence; when it wants to say something to some other, from itself and care about the result/response/answer, or if it wants to exchange data, and in fact any other foolish things you may imagine possible then it will be a query.

But then you say: if there are only 3 possible events, how do you make differenciation between all the features? The answer is simple: thanks to the namespace. Each event (whichever it is message, presence or query) will have a namespace which implies a different feature.

So I was saying, you are in the world of Jabber and it is silent (you are at level one of the XML stream, everything new always happens at level one!). Then you receive one of the 3 events and you answer if necessary (which is only for IQ, unless for errors), and you can create events and wait for their answer if necessary (again only for IQ).

And this is all!!! Now you have the whole Jabber structure. For the rest, it is details about what feature you want to add, etc.