Introduction

There are some minor design decisions in PogoBOT that I would like to change my mind about. Unfortunately, this requires revision of the entire protocol, so we're almost starting from scratch again.

Aims

The PogoBOT project aims to write an IRC bot.

Design

We are considering the use of UNIX sockets instead of INET ones, since we can get some basic authentication from them.

Protocol v1

The original PogoBOT protocol looked like this:

command1[ arg1[ arg2[ arg3 [...]]]]<tab>command2[ arg1[ ...]]<tab>command3 ...

Upon receiving a line, a PogoBOT module was expected to:

So the reply line would look something like:

command2[ arg1[ ...]] reply<tab>command3 ...

This allows for daisy-chaining of commands, and kept the core very simple, almost stateless. This turned out to be a disadvantage; it becomes very difficult to detect infinite loops and so on. It also makes the modules more complicated than they have to be.

Protocol v2

Let's have another go. A module will receive something like this:

reply-to<tab>command<tab>arg1 arg2 ...

The reply will look like:

reply-to reply

Example code

With this new protocol, we could for instance implement an 'echo' plugin in one line of bash:

echo "REG echo"; IFS=$'\t'; while read replyto command args; do echo "$replyto $args"; done

or, if you allow yourself use of cut:

echo "REG echo"; while read line; do echo $line | cut -f 1,3; done

or even:

echo "REG echo"; exec cut -f 1,3 --output-delimiter=' '

or with awk:

awk 'BEGIN{print "REG echo"}{print $1 " " $3}'

Example core <-> module dialogue

An example of a module implementing 'echo':

<module>REG echo
  <core>OK REG echo
  <core>1234	echo	Yarr!
<module>1234 Yarr!
  <core>2097	echo	Foo bar.
<module>2097 Foo bar.
  

An example of a module that does some processing of its arguments:

<module>REG calc
  <core>OK REG calc
  <core>98535	calc	123 * 456
<module>98535 560388
  <core>6743	calc	scale=30; 4*a(1)
<module>6743 3.141592653589793238462643383276