Last month I mentioned I was working on an IRC snowball and expected it to be complete in about a week. Well, that didn’t happen. Between being busy with other projects (such as light construction, ugh) and shear procrastination, it’s taking longer. Here’s the current/future TODOs:
Rest of the RFC2812 command wrapper procedures.
Figure out how to get SchemeDoc to recognize define* as it does define.
Clean up the documentation.
Have someone else proofread the documentation.
Add handlers for the required CTCP replies.
Add a handler for case where desired NICK is unavailable at connect time.
Possibly replace all the record shit with a simple object system.
Make the default handlers use the same API the users are expected to use.
3digit codes -> ERR_* RPL_* at parse time, such that snirc:msg-command could be ERR_NOSUCHNICK or whatever. Get rid of snirc:msg-code.
cl-irc has a lovely alist of this mapping in its code. Should find out if its author minds it being borrowed, considering this code is BSD licensed while cl-irc is not.
Figure out why the fuck I couldn’t match against snirc:msg-code, even though it’s likely to disappear anyway. It’s probably due to my noobishness, but possibly a logical error somewhere. Need to know.
Merge snirc:cconnect into snirc:read-message-loop. Seriously, there’s not much reason for it to be seperate and there’s not really a logical name for it that I can think of considering snirc:connect is taken for a wrapper to RFC CONNECT. snirc:read-message-loop already checks if it’s connected at startup anyway.
Handle exiting/disconnecting/quitting cleaner. Make it never go to debugger/error/whatever. It pretty much just needs to be more careful about not trying to read from a closed socket.
Possibly split the RFC command wrapper stuff from the internal connection/handler stuff into separate files. Maybe the existing/future CTCP/DCC stuff should be in their own files as well.
Handle PINGs required for connection registrations. A solution to this is for the user to wait to send non registration related commands until we’re sure it’s complete, from within read-message-loop (which will handle the PING), such as this handler which deletes itself when it’s no longer needed:
(snirc:add-handler! conn (lambda (msg) ;; Numeric 001 is the welcome message ;; after a successful registration. (if (string=? "001" (snirc:msg-command msg)) (begin (snirc:join conn "#Some_Channel") (snirc:remove-handler! (snirc:msg-conn msg) 'temp))) #f) tag: 'temp)
This “solution”, however, is crap. It’s somewhat difficult to describe clearly why it works, and it is reasonable for the user to expect snirc:register-user to finish its job and be able to call snirc:join, snirc:mode, etc… before calling snirc:read-message-loop anyway. Why some servers want to send a PING and demand a PONG before completing the registration, I havn’t a clue. Also the tested server sends the PING after it receives NICK, but it is happy to wait for the PONG until after it receives USER. If it demanded the PONG before receiving the USER command, this would have to be more complicated.
If you ask me, the “proper” solution would be to remove this crap from the servers stupid enough to do it in the first place. The only even remotely logical use of it I can think of is for the server to adjust how much idle time should go by between pings to save an irrelevantly small amount of bandwidth, if it were also too stupid to check the reply times of later PINGs, and there’s no reason it couldn’t send an initial ping *after* registration anyway, even if for some reason the latency between the client and server were somehow magically guaranteed not to change during the lifetime of the connection. Not to mention that given such, if a client wished to deal with fewer PINGs it would artificially wait some time before sending a PONG anyway. The whole thing is entirely senseless, I can’t for the life of me figure out any other reason for it what so ever, and even if there *is* a good reason for it I don’t care as it’s arguable (and I would argue it) that it violates the RFC anyway.
SSL/TLS support. Not likely to happen until someone else provides a snowball that deals with SSL/TLS. I could break out my copy of Applied Cryptography and take a look at existing encryption-related snowballs, but really there’s many other things I’d rather work on.
Support for the rest of CTCP such as colors(ew) and what not? At least an option for the parsing mechanisms to strip the colors and crap out of messages to ease the writing of bots. As far as actually doing anything with them, that’s probably best handled via code in a client being written using this snowball.
DCC support (technically a part of CTCP, crap bolted onto crap bolted onto IRC…). Will require threading, or something in the vein of select/poll.
Docs for the RFC command wrappers.
Even though it’s basically redundant and involves rewriting bits of the RFC, and the wrappers are so thin they’re pretty much translucent.
If the RFC command takes an optional ‘target’ parameter, then so does the snirc procedure, &c.
I would just copy the relevant bits of the RFC and adjust the examples it gives, but although it seems fairly liberal I’m unsure as to whether its copyright would allow for such use. As far as I can tell: no. I’m just an unpaid code monkey, I don’t speak legalese.
As long as I’m wishing, I wish that all existent RFCs were relicensed under the Creative Commons or public domain or suchlike. Besides making my docs easier, it would perhaps prompt someone to clean up much of the the RFC protocol, which while writing this snowball I’ve become entirely convinced it badly needs. MODE in 2 different sections with 2 different uses comes immediately to mind, as well as the grammar of different types of commands being different enough that you wind up with silly shit like having to check the sender to see who’s nick changed and suchlike without making the parsing code vastly more complex, or the fact that notifications such as those share the names of the commands used to cause them in the first place, such that MODE actually means *three* things, depending on whether you’re sending or receiving it… It would also be lovely if CTCP wern’t crudely bolted on top of IRC, with DCC bolted onto CTCP in turn. The RFC could very well provide CTCP/DCC commands directly. And if you had a real reason to add stupid shit like registration-time PINGs, a new RFC would be the place to do it.
More state tracking ala cl-irc (who’s in what channels, user/chan modes, etc…).
Possibly update records with relevant server replies re: whois and etc…
Possibly in addition to, or instead of the above, provide a FIFO queue (string port? list?) that contains numeric server replies (say, the last 20 or so).
Really, both of the above can be handled by the user. It would just be nice, and not that hard to do.
Replace all the record shit with a simple object system if not done already?
Multiple server connections. Will require threading, or something in the vein of select/poll.
Perhaps it is cleaner to have the user use their implementation’s threading system, and call an snirc:read-message-loop for each connection.
It’d just be really nice if they could simply pass snirc:read-message-loop a list of connections and let it deal with the threading instead.
Plus the message records know which connection records they belong to, and we need to be able to handle multiple sockets for DCC support anyway.
Add a socket control interface. Same requirements as DCC and multiple servers.
Think out of band communication between applications using this snowball, or clients/bots that can be written in any language the user damn well pleases using this snowball as a backend through a local (or remote) socket, maybe even a web app. I really want this.
Bonus points if it can use SSL and/or TLS, thus making remote possibilities saner.
There are snowballs to talk to other processes. Make it fall back to netcat/socat/telnet if snow doesn’t know how to open a socket in the implementation. Hopefully one or the other will always work. (Also, I’m pretty damn sure Chez and SCM can open sockets, the tcpip snowball should be updated.)
SILC support? Have to see just how different that protocol so far as commands and whatnot from the client’s perspective is. I’d hope it’s much cleaner, but if not it may be worth adding to this snowball. Also, would require SSL/TLS support.
Some sort of juju to torify ourselves?
Perhaps by talking directly to Tor’s socks4 or socks5 proxy?
Perhaps by skipping the tcpip snowball altogether and using netcat &c through torify to open the connection?
Probably will never happen, it would be pure feature bloat.
No comments yet.