Dyalog APL introduced their new communication toolbox Conga a few years back. This week they are presenting the latest (upcoming) version 3.0 in the annual Dyalog user meeting (this year in Glasgow), which promises enhanced features such as built in http and websocket support. I got my hands on an early build with the aim of testing the new features and provide feedback to their development team.

I was particularly interested in the websocket feature as it is something I have requested and also implemented myself in Dyalog APL early last year. At SwedAPL 2015 (the Swedish APL user meeting) I presented my websocket implementation and demonstrated a couple of example applications. One of them was a simple chat web app, a typical situation where you need to distribute messages to all clients connected. As part of my evaluation of Conga 3.0 I replaced my websocket library on the back-end chat server and ended up with a much simpler solution that fit in a single function of about 30 lines.

A few days later a colleague sent me a link to kchat: a chat web app with a k back-end. The back-end code fit into 3 lines of k, or 8 in a “verbose” version. As k is a not too distant relative of the APL family I checked the code and tried to understand how it works. What surprised me wasn’t so much that it only took a few lines, but the fact that there was no obvious setup of a server in any of the code I was looking at.

After a few hours of reading up on the basics of k and their communication tool IPC (interprocess communication) I downloaded and “installed” their free 32-bit interpreter (there isn’t much of an installation required as the interpreter is very portable and self-contained). It took me about 5 minutes all in all to download and install k in a non standard folder on both my Windows 10 and Ubuntu 16 machines. I started up the interpreter, which by default goes into q mode, a superset of the k language. It took me longer to find out how to switch to k mode (just type a single \ in the q session and hit enter). After that I was ready to code.

As I said, I couldn’t find anything in the kchat code to suggest it was running a server. Going back to the instructions I spotted that the script should be launched by running the command “q chat.k -p 80”. That was the first clue right there: the interpreter is started with a commandline switch to tell it to listen on port 80. The actual chat.k script itself defined 3 callbacks:

.z.po triggered on a client connection
.z.ph triggered on a http get request
.z.ws triggered on a websocket message received

Going back to the documentation I learnt that I can define the port to listen on with the command \p. So what would it take to build a simple “Hello World” http server? I launch a command prompt, start the interpreter and execute the following lines:

\
\p 80
.z.ph:{"Hello World!"}

I launch a browser and navigate to http://localhost and voilà, I see a blank page with the text “Hello World!” in the top left corner.

To accomplish the same using Conga 3.0 I need to load the DRC script, initialise it, start a server, create an event loop and respond to requests that way. The shortest way I can express this is:

'DRC'⎕CY'conga'
 #.DRC.Init''
 rc srv←2↑#.DRC.Srv'' '' 80 'http' 10000
 {
     rc c e d←4↑#.DRC.Wait ⍵ 1000
     e≡'HTTPGet':#.DRC.Send c'Hello World' 1
     ∇ ⍵
 }&srv

Now that isn’t too bad, but wouldn’t it be nice to be able to skip all that and use the same approach as in k? How about a new system object that deals with the comms part and event loop:

⎕DRC.port←80
 ⎕DRC.onHTTP_Get←{
     ⍝ ⍵ ←→ client object with details
     ⍝ ← ←→ data to be returned
     'Hello World'
 }

If the system object has thread scope (like ⎕DMX) then you could start multiple servers on different ports for different purposes (RPC/HTTP/WS).

Now, I don’t have enough experience with either k or Conga 3, but the simplicity of k is definitely appealing.