emiln / clojirc Goto Github PK

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#STATS

When interacting with IRC, I often want to work in an event-driven manner along the lines of "when one of these events happen, call this function". Furthermore, I don't want to worry about these listeners "consuming" the original event; one event should be able to trigger a multitude of listeners.

A simple example:

(let [messages (events-by-command network :privmsg)
      notices (events-by-command network :notice)]
  (go-loop []
    (when-let [{:keys [trailing]} (alts! messages notices)]
      (println "I just saw:" trailing)
      (recur))))

This should respond to any PRIVMSG or NOTICE and simply print the :trailing part.

The most basic form of the event subscription should be something along the lines of (events-by-predicate network pred?), but I can imagine several useful functions returning channels building upon this:

• events-on-channel: puts messages onto channel if it happened on the given channel.
• events-by-command: puts message onto channel if its :command matches. It should take any number of arguments and match if any one of them matches.
• Etc.

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#SERVICE

The officially supported commands should produce output strings adhering to the spec. A simple solution is to test the examples provided by the specs.

The command parser for private messages currently will return an error if a message from a nick with an underscore is received. This is a possibility on most networks, and should be rectified.

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#ADMIN

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#USER

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#JOIN

All command tests in the clojirc.commands-test namespace repeats a bunch of code. I am not usually a big fan of macros for tests, but I think it is warranted here.

(let [channel (async/chan)
      network {:to-network channel}]
  (expect
    "ADMIN tolsun.oulu.fi"
    (do (cmd/admin! network "tolsun.oulu.fi")
      (async/<!! channel))))

could become something like

(command-expect
  "ADMIN tolsun.oulu.fi"
  (cmd/admin! "tolsun.oulu.fi"))

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#WATCH

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#ENCAP

For functions like login! it would make sense to return a promise that will be delivered when the server acknowledges having received your message. The current implementation returns the network you fed to the function, which would make sense for a pure function, but much less so for these highly mutating functions. Ideally the promise will be delivered with the server's actual response message.

This will also allow users of the library to await the completion of their commands, which would be great. You'd just deref the returned promise.

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#PRIVMSG

It would be nice to be able to specify a rate-limited channel to use as a buffer between your code and the network IO. I can imagine several implementations:

• A flood-protected channel, which will only send a certain number of messages per second to not ever cause flooding.
• A "CPM"-based channel, which will delay a message based on how long it would take a human being to type it on the keyboard. A simple strategy could be to count the characters and assume a steady characters-per-minute speed of typing.
• An "at most k messages per n seconds"-respecting channel, which will never send more than k messages over any period of n seconds, but may reach the k messages as fast as possible.

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#LUSERS

https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands#NOTICE