It doesn't look like the package would be all that hard to port to OpenACS 4/PG ...

Did aD provide a Javascript client or just the Java interface for the 4.x version?

Anyway ... what do folks think?  I know some folks are more interested in interfacing to Jabber and possibly IRC but having a standalone chatter package doesn't mean we can't latter support other options.

Rocael - I think the design of the existing ACS 4 chat package would eventually become obsolete.  Even in the short term the transcript logger probably wants to hook up to the RSS package to allow offsite  logging of the transcript.  In the longer term it may need to support various protocols as mentioned above which would probably mean modularizing it to a fairly high degree.

I think, anyway, I haven't thought much about it (maybe others have?)

But maybe having a port of the existing chat (interfaced with the RSS package?) would start the ball rolling towards a more interesting future version.

So, I suggest keeping the original http ACS chat, and adding at least one of the others...

I have had some pressure to produce a near-term chat solution on OpenACS 3.2.5, so this looks pretty good to me.  I would definitely be interested in the backported module and your documentation of the installation process.

BTW, were we at the ACS 4 boot camp together last year in Pasadena?

Meanwhile, it looks like you're keeping really busy with OpenACS projects.  Refresh my memory...do you run your own consulting business?

Looking forward to checking out your chat backport....

I look forwared to be able to replace our current ACS chat with your alternative.

Malte just released a jabber module for AOLserver... It might help you with your Jabber task:

http://www.sussdorff-roy.com/jabber/jabber_inst_main_doc.html

I am looking forward testing your ACS Chat backport...

I find moderated java based chats pretty useful for discussions involving one "expert" who gives answers and many people that post questions... The thing about those moderated chats is that a moderator intercepts all the questions and posts only those to the public that are being answered... This way you could cut off unwanted commercial posts in big public discussions. Also if too many people posted questions at the same time the answers of the expert would get out of sight pretty quickly!

Have you done anything in this field?

It maybe usefull to know I have a professional testing team of 8 corporate secretaries available on-line every working day. So if you would like to get some feedback from chatters, that have been using the current ACS chat, aswell as www.chatspace.com, let me know what we can do to help you with the usability testing. I can assure you they realy can be fussy )) . By the way the same counts for any other modules. Theare are curently using the Intranet, which I am currently using to give them on-line offices and homepages.

Julie, soon you'll see that.

After reading the Jabber mailing lists for six months or more, I finally got an idea on what kind of software should be built into AOLserver to interface with a Jabber server. Instead of writing a client, as I did, and I guess Malte and his students have done, the thing that is needed is a Component. The most relevent link is http://docs.jabber.org/general/html/component-intro.html, but generally a component uses a slightly different protocol than the client protocol, but once authenticated to the server, it acts as a part of the server. My suggestion is to write an AOLserver C module very similar to my current module, but connecting as a component. My Jabber module is relatively simple: it simply passes a reference to each packet into the tcl api. It also wraps the most useful packet handling api functions in libjabber. The main downside of my module is that libjabber seems to be an abandoned library. I think there might be a more useful library somewhere, but I have not been able to find it. I did replace some of the libjabber implimentations to better support detecting server/client disconnect. Currently the software required to use this module are at http://zmbh.com/nsjabber/ I wish I had installed Malte's module for comparison, has anyone else compared the two?

I spent some time today looking at the jabberd library. It has some of the same stuff as libjabber does, what is missing is the jconn structure which maitains info about a jabber connection. Hmm, how do they do this in jabberd. Probably I would need to re-write the connection parts of the client/component.

The benefit of writing a module that can act as a component is that then AOLserver/OACS becomes a jabber component which can offer services to any jabber server. These services can be anything, and might be easier to do in our favorite software than in perl/java/...

As a client, I think you can hack your way to a workable solution for some of these things, but as a component OACS/AOLserver would be part of the Jabber server, or maybe would use the Jabber server as it's dog for all the routing stuff. As a component, the Jabber server would see the OACS as: a user database, a content library, an email conduit, a blog, only depending on the programming done in OACS/AOLserver. The truth is the Jabber community is very good with the plumbing, and IM, but not too tuned in to the http type applications most of us are used to: bigger, fatter and not necessarily human attended. The one painful application I saw, which introduced me to Jabber in August, I think it was a survey bot, could probably be done with simple survey with a little hacking. The example I saw was never finished, so difficult to use is the perl library for anything beyond chat.

One thing to note also, is my module gives a great example of using one client connection that de-multiplexes into OACS with the dqd threadpool module so that database activity doesn't slow things down. So you end up with one thread in, many execution threads, and one thread back out. Another interesting feature I discovered is the ability to inject (like internal redirect) packets into the stream, to skip from one 'url' to another. I also experimented using the thread tag as a url. All of this would have been painful, I believe, except for the fact of AOLserver/Tcl. Anyway, having two OACS/AOLserver setups would allow using some kind of specialized namespaces to transfer data. One thing to note is that jabber packet size maxes out at at most 500k, but again a namespace might be developed to allow message disassembly/reassembly.

This could be scoped per instance per package, so that, for
example, I can get pager alerts from my tech support bboard but
not from my app design bboard. Certain apps might conceivably
even want finer scoping than this. For example, I might want
ticket-tracker to give me pager alerts for new bugs assigned to
me but not for messages letting me know that particular bugs
have been closed.

On the other hand, the list of conduits available to the user (from
which these preference dialogs would be drawn) should be
scoped to the user, i.e., I shouldn't have to re-enter my email
addresses, pager numbers, etc., for every scoped application.

JDK 1.4 is ok, what linux are you using?

About the java stuff, its pretty easy (although I don't know really what that minor warning...)

When you have changed the appropiate *.java files, run javac *.java if you want, but what you really need to do is generate a complete applet .jar, that's the file that jchat.tcl calls.


So run this simple command in /web/yourservice/www/chat

jar cvf chat.jar chat/

This should work.

I also had to define the full path for the exec command although I am able to start java or javac from the command line (nsadmin and root)...

Things are more difficult as I am using Jerry Asher's nsunix modules... This will forward http://myserver.net to unix://myserver.nsunix

master.tcl:

ns_section  ns/server/master/module/nsvhr/maps
ns_param    myserver.net    unix://myserver.nsunix
ns_param    myserver.net:80    unix://myserver.nsunix

I have not specified any ports (and still normal http works):

myserver.tcl:

#set httpport              80

Would it be possible to use the chatserver on port 80 together with http? Or should I make a new nsunix socketfile? Dunno. Well, I'll try things out.

The jchat doesn't care about nsunix or stuff like that, just asign an IP, a port, and thats it!

One thing that maybe needs some changing is the private chat. When the entire window is full with messages (like 5 from both users) new messages do not appear - that is, until one posts a couple more messages so that the 'old' ones are pushed up. (I hope this is understandable...) Is there a solution for that?

Okay, the software I wrote is a jabber client. A tiny rewrite or addition to the C code would allow connection as a component. You would not necessarily need to do this for your intended purpose: sending messages. Just like bboard alerts, messages can be from a single account (bboard@openacs.org). However, my module also connects to any jabber server as any user, assuming you have the password, so each module could setup it's own connection and send messages as it wishes. All you need to do is to write the code that figures out the jabber user address 'user@domain/resource', build the xml (easy) and send. The jabber coding only takes a few minutes.

Very cool, Tom.

1) My fix for auto-scrolling to display the latest messages is to add a couple lines to the source files:

a) At the end of the receiveMessage method in the adChatApplet.java file, add the following (at line 372 in the original source):

    // Auto-scroll to display the latest message
    int height = text_area.getViewportSize().height;
    text_area.setScrollPosition (0,height);

b) At the end of the receiveMessage method in the adPrivateChatFrame.java file, add the same lines (at line 120 in the original source).

c) Recompile (let me know if you need the details).

c) I also had to close existing sessions to get my browser to reload the recompiled applet.

3) Are you getting the connections lingering on your chat server port? It would help to know if anyone else is getting these stale connections, so I know whether to look at the OS or the chat server code. Interesting that you should point to that link. I've secured and optimized my machines by following those instructions to the letter (and I've been extremely happy with the resulting configuration). So I've already implemented the recommended network optimizations.

It will work...

Meanwhile, Michael's comment supports my (untested) suspicion that the socket connections aren't getting closed when someone leaves the chat without clicking the "Log Off" button.  I think that will be a relatively frequent occurence, so it would be nice to figure out how to close those connections down properly.  My tests have been pretty limited, with only a couple users in brief chat sessions which generated a number of stale connections, and I wonder what the implications would be for a production environment.

Michael, do you think it's appropriate to handle the stale connections by changing the OS configuration to time them out?  It does seem like it would make sense for them to be dropped eventually, because right now they appear to linger indefinitely or until the chat server is restarted.

Should the server close the connection when the other side is disconnected from the network, you would see FIN_WAIT state in netstat.

conclusion: that seems to be a bug in the server.

For those interested in a sound alert when a message comes in, here is how I did it:

At the end of the receiveMessage method in the adChatApplet.java file, I added the following:

       // Play a sound effect when the message arrives
       AudioClip audio = getAudioClip(getCodeBase(),"message-notify.wav");
       audio.play();

That's more interesting stuff....  I'm especially curious about the HTTP tunneling.

The issue of traversing corporate firewalls is unfamiliar to me, so let me see if I have this straight.  As I understand it, the firewall restricts traffic to familiar ports with one or more specific protocols associated with each open port.  So to get stuff in and out of port 80, it needs to be http?  Is this what is meant when people say they can't use java because they're behind a firewall?

The issue that comes to mind is that you can only have one service listening on a given port.  So if you have AOLserver listening on port 80, to my knowledge you can't share that port with a chat server.  Does that mean you would run the chat server on port 80 on another IP address?  Or would the chat server, or some kind of http tunneling middleware, be the service listening on port 80, brokering the requests and routing them to the appropriate web/chat server?

I'm kind of thinking out loud here, trying to understand this stuff, but if you have an answer I'd be interested.