Forum OpenACS Q&A: Jabber Client for AOLserver

Collapse
Posted by Tom Jackson on

I have hacked togeather a very preliminary Jabber client for AOLserver. Right now it only does one thing: record groupchat.

During this process I have discovered a number of realities. The most important of these is that a webserver will never be a completely satisfactory chat client for the end user.

Another reality is that AOLserver will make a great jabber client because of the single process design. It can easily stay connected to the jabber server on a continuous basis, listen to and record groupchat, maintain online member information in virtual memory, send and receive messages. Since jabber connections are authenticated, you might be able to rely on that to allow posts via jabber to a bboard.

Jabber has three main xml tags: message, iq and presence. Both iq and presence are volatile and don't need to be saved to a database. However handling of the processes that use iq and presence will be the biggest challenge in developing a full client.

Since this jabber client will be built into a great webserver, with a full scripting language and database support, it should be much easier to add nice features that the jabber community seems to be struggling over.

You can test out this module at http://jabber.zmbh.com:9000/

I'm sure the setup can be abused, and the jabber server might be down at any given moment, so try to enjoy it, and post any questions here.

Collapse
Posted by Kenny Chan on
Tom,

This is very interesting, Aolserver as a Jabber client. Is it being implemented by ns_socket and etc. from the Aolserver API?

Have you checked out IRCG? It is a IRC client implemented by PHP and thttpd. The performance of it looks really impressive. I have always wondered if equal or similar things can be done with Tcl and Aolserver.

Btw, is the ns_jabber code being opened?

Sincerely,

Collapse
Posted by Tom Jackson on

Most of the code is inside a c module. Here is what runs the client right now:

nsv_set jabber_conn user [ns_jabber new "user@server/res" "pass" ]

# start this jabber_conn and auth the conn
set j [nsv_get jabber_conn user]
ns_jabber start $j

# wait a while for a response, this could hang the server
ns_jabber poll $j 50000  ;# microseconds
ns_jabber auth $j


proc do_poll { j } {

  while { 1==1} {
   if {![ns_jabber stateget $j]} {
    ns_log Notice "Jabber Conn $j is Off"
    break
   }
   ns_jabber poll $j -1
  }

}

# Schedule the polling proc and see what happens
ns_schedule_proc -once -thread 5 do_poll $j

However, all the new, start and auth procedures should be moved into the scheduled procedure and inside the while loop. The value of the state can be used to decide if a new connection is needed. If the connection goes down, it can restart immediately. If the whole thread dies, then it will be rescheduled.

Also right now I haven't protected the send socket. So problems could occur.

Collapse
Posted by Ben Koot on
Hi Folks, In my search for alternatives to upgrade chat I came across this package.. freewebphone Freewebfone for Windows combines web video phone, chat, voice & video mail into a single program. It supports H.263 for video and GSM, ADPCM, and LPC10 for audio. A FREE Internet User Location Service is provided for all Freewebfone users. Users can make web phone calls as easy as normal phone calls. User Location Service also supports popular online features such as Buddy List, Instant Alert, Online Chat, Invisible Mode. Web broadcasting service is also available. Freewebfone is a Cross-Platform software and is currently available on Windows, Linux, and Macintosh. Users can now make web phone calls or send video/voice mail across these most popular platforms.

Now given my limited technical knowledge, I may be trying to compare apples to pears, but I was wondering if it would be feasible to use something like this to spice up the current rather pathetic acs chat as you in dictated earlier. As you will see there is a "mini jabber" application, that might make life easier

Look forward to hear from you

Collapse
Posted by Michael Feldstein on
Nice, Tom!

There are some tantalizing hints about how you could use Jabber in conjunction with XML-RPC here: http://jabber.org/?oid=2001

Collapse
Posted by Tom Jackson on

Okay, I setup a weblog type thing at http://jabber.zmbh.com:9001/. To use it you need to register at multi.zmbh.com with a jabber client, then send messages to jabber@multi.zmbh.com/as.

Collapse
Posted by Tom Jackson on

Since I rarely read much beyond the emails from this discussion group and the one for AOLserver, I didn't hear about Jabber until I picked up Linux Magazine in August. In the article, the author discusses building a survey 'bot'. Apparently any automated client is called a bot. This client will let you pick a survey and then answer the questions. Everything sounds good until you investigate further and find out that this relatively simple application is difficult to program, and hasn't even been finished!

I guess it shouldn't be a surprise, since it is written in perl and attempts to maintain a mini-database of where the survey taker is in the process.

My first module relied on two assumptions: presence and iq packets didn't need to be saved, since they are session like pieces of information, and message packets should be saved. So I stuffed the messages into the database inside the C module.

The problem with this approach didn't take long to surface. Flexibility was definitely lost. A single thread was used to respond to every packet. Stuffing messages into the database turned out to be a dead end in the world of async jabber communication.

It became apparent to me that I needed to expose every packet directly to the tcl API as quickly as possible and move on to receiving the next packet.

So here is what I did. A diagram might help. A schedule procedure makes a connection to a jabber server. This thread essentially runs a a loop that maintains an always up connection. This thread receives every packet for this connection, checks to see if it is zero length, which would indicate the jabber server died, and then calls TCL_EVAL, passing the text representation of the packet to a tcl procedure.

The tcl procedure, still being run inside the scheduled procedure thread, passes this data on to another thread, using Rob Mayoff's very useful threadpool module. At this point the scheduled procedure thread reenters the select loop waiting for the next packet.

One of the threadpool procs runs the command that was queued. This command is essentially the head procedure that will decide the ultimate fate of each packet.

So that handles data passing into the AOLserver tcl API. Each procedure that wants to pass data back out, again uses Rob Mayoff's threadpool module, but in an unexpected way. The maxthreads is set to one. This essentially places a ns_cond around the outgoing socket, and provides a queue for the socket as well.

Here is the diagram:

                        pool1.1
            sched:4  |----------> |   pool2.1
sockin      -------> |----------> | -----------> sockout
                     |----------> |

Pool1 will handle the bulk of the work.

Jabber is a stateful protocol, completely unlike http. However web applications have developed means to recover state with each connection. Most jabber clients have very limited means of preserving state between connections. By exposing a jabber connection to the AOLserver API, it should be significantly easier to develop useful applications using the jabber protocol, but there are still significant barriers.

One barrier is that jabber clients are relatively dumb. Most of the functionality from jabber is supposed to come from the use of xml. The main problem with this is that xml is not a programming language. Although clients are required to parse xml, what to do with it once parsed has to be decided in advance. This means that clients have to be developed per application. This is obviously a big problem.

Most user clients (Gabber, WinJab, etc), understand a few message subtags: subject, body, thread, x. What to do with x tags is unknown. The thread tag may turn out to be the most useful. The client is supposed to return the thread tag unchanged. It might be possible to use this feature (or the id attribute of the message tag) to move the user client through the application. It might be able to serve as a crude form of url. Combined with the body data, you can envision a rudimentary browsing application.

Collapse
Posted by Tom Jackson on

I just had an idea while reading the Jabber Development forum. Crazy, probably: package AOLserver and the jabber client module as a jabber client for regular users. It seems the harder parts of writing a client is the UI. Also, if you want to exchange files, you have to write an Out Of Band method. This would be easy if the client was also a webserver.

Main problem is that to see wide use, the client would have to run on windows.

The client I am working on is coming along very well. A bot is available at weblog@pathfinderschool.com/ws, and provides a menu of echo, time or login to ACS. Unfortunately the login doesn't record the JID of the user. I guess eventually this could be used for a 'whose online' type feature, or for logging messages or running other user applications.