Stats responses are incredibly non-standard and no clients render
them correctly. This makes using /STATS a massive pain in the ass
for users.
However, now we have message tags we have a way to fix this. We can
send a <trailing> with the message details and for clients (probably
bots) that need to parse the response we can include the specific
details in message tags enabled by the new inspircd.org/stats-tags
capability.
The average user will get this:
:<server> 210 <nick> <stats-char> :<stats-message>
If however they enable the newcapability they will get this instead:
@inspircd.org/stats-foo=bar;inspircd.org/stats-baz=bax :<server> 210 <nick> <stats-char> :<stats-message>
The numerics we used previously were not being used according to
the RFC and every implementation has their own behaviour here which
makes it hard for clients to do anything reasonable. Instead of this
using the generic stats numeric makes a lot more sense.
- Allow overriding privileges from the <class> blocks in the <type>
and <oper> blocks.
- Separate oper types from oper accounts in the code. This enables
moving some core stuff out of the config tag later.
- Merge the config tags together to make a synthetic tag that can
have getXXX called on it instead of using getConfig and then
converting it.
- Move the details of Have*Permission into the oper type class.
- Improve oper events to allow modules to easily hook into the oper
system.
- Ignore SIGPIPE to work around IO::Socket::SSL having its socket
closed from under it and terminating the program.
- Improve detection of servers that close the TCP connection right
after it is opened. This usually means the IP address the tool is
connecting from has been banned so suggest that as well.
- Show more debug information when a connection fails.
A Cap::Reference can not be cast to a Cap::Capability& because it may
not be available and that would create a null reference. In v4 we can
change the API to take a Cap::Capability* but for now this is the best
we can do.
