Add MOTD module

[daurnimator]

I wanted to have a play around with making a stateful module; MOTD seemed easy enough for a first try.

This code assumes each irc object can only have one MOTD in progress at a time.
==> If you query multiple servers; can they come in interleaved?

[mirrexagon]

I was intending to have all state handled by the host program with IRCe just being a thin translation layer, although now I see that might not be the best idea in terms of ease-of-use. I'll have to think about this.

This reminds me of channel name lists. I have a handler that inteprets RPL_NAMREPLYs but I just return each interpreted line as it comes. I might make that stateful. Again, I'll think about it.

As for multiple servers/MOTDs, you could check the message prefix (ie. sender[1]) and sort each server's MOTD by it.

[mirrexagon]

I'm also not sure if raising errors in a handler is a good idea.

[mirrexagon]

Also, I wonder if it'd be better to keep state in the IRC object itself (like in self._motdstate or something).

EDIT: Actually maybe not, I don't really know.

[daurnimator]

I was intending to have all state handled by the host program with IRCe just being a thin translation layer, although now I see that might not be the best idea in terms of ease-of-use.

Much of IRC requires state: many results arrive over multiple lines.

This reminds me of channel name lists. I have a handler that inteprets RPL_NAMREPLYs but I just return each interpreted line as it comes. I might make that stateful.

Sounds good :)

I'm also not sure if raising errors in a handler is a good idea.

What will happen? I assume it would propogate to where :process was called?

Also, I wonder if it'd be better to keep state in the IRC object itself (like in self._motdstate or something).

I thought of that first; but it's not really extensible.... don't want to deal with clashes etc.

One option would be that modules are passed a 'state' object they should use?

[mirrexagon]

I'm also not sure if raising errors in a handler is a good idea.

What will happen? I assume it would propogate to where :process was called?

Yeah. I guess the host program could pcall irc.process. I'm avoiding raising errors in handlers in favour of reporting them to callbacks (or else just silently ignoring them), especially ones out of control of the program (like MOTD messages coming out of order).

Also, I wonder if it'd be better to keep state in the IRC object itself (like in self._motdstate or something).

I thought of that first; but it's not really extensible.... don't want to deal with clashes etc.

One option would be that modules are passed a 'state' object they should use?

Local state sounds the best out of the options after all; that shall be what I'll use.

Regarding your MOTD module, are you going to try sorting MOTDs by prefix to get around the possible multiple-server-interleaving issue? (I've tried to implement something like this in the NAMES list handler, but I'm not actually sure it's even necessary; it probably overcomplicates it.)

[daurnimator]

Yeah. I guess the host program could pcall irc.process. I'm avoiding raising errors in handlers in favour of reporting them to callbacks (or else just silently ignoring them), especially ones out of control of the program (like MOTD messages coming out of order).

I figured letting a broken server continue would be useless: raising to the irc:process should ideally result in a closing the connection.

Regarding your MOTD module, are you going to try sorting MOTDs by prefix to get around the possible multiple-server-interleaving issue? (I've tried to implement something like this in the NAMES list handler, but I'm not actually sure it's even necessary; it probably overcomplicates it.)

I don't know if sorting is the correct solution; I was more thinking about indexing by a compound key of irc object + server.

[mirrexagon]

I figured letting a broken server continue would be useless: raising to the irc:process should ideally result in a closing the connection.

Ah, makes sense.

I don't know if sorting is the correct solution; I was more thinking about indexing by a compound key of irc object + server.

I think I should have worded that better; in the NAMES handlers I've experimentally tried indexing like so: state[irc_obj][prefix][channel] = list_of_names (feels a bit unecessary for the NAMES handler, but I'm not sure (also I probably shouldn't be using that many nested tables, compound keys sound good)). That's what I meant when I said "sorting".

[daurnimator]

I've just updated this PR to use the "state" variable now passed to module functions.