ctcp; some dcc stuff; an attempt at plugin prefixes

[foghawk]

trafficstars

[eevee]

some comments:

• can you rebase these first few commits together, and fix the mode changes while you're at it? bunch of files got changed to 755
• no_respond doesn't seem to do anything?
• please indent new files with four spaces :)
• you may want to give pathlib (has a backport, which is already a dependency for dywypi) a whirl in lserv instead of os.path

DCC as a dialect is interesting. seems like it should be married a little more closely to IRC, being a sort of sibling protocol, but offhand i don't have any great ideas that would still keep it super easy to send plugin events. i don't really know how to handle two plugins that both want to do DCC stuff (like receive files) either. will have to ponder on that a bit more.

the DCC client could probably be simpler using a stream, which i've been converting IRC to use, but i can do that part

also if you can describe how some hypothetical tests would look i could take a crack at writing some; definitely want to get a test suite going sooner rather than later

[foghawk]

• done
• it just tells irc to use NOTICE instead of PRIVMSG
• done :)
• done

dealing with multiple DCC things may be kind of a moot point right now—any plugins that create clients of their own (DCC or otherwise) aren't able to use or respond to those clients' events at all. event loops get advanced in the brain; the brain keeps track of those event loops by their networks; the brain never gets a reference to any network created outside the command line. this strikes me as an issue, but frankly i've no idea how to tackle it (beyond giving every plugin a reference to the brain, which seems Bad). i'm not sure if it's really an architecture issue or just demands deeper magic than i've got

if you're switching from transports to streams, i may hold off on actually implementing file transfers until that's done; the SEND spec (or at least the part of it that anybody follows) has some Opinions about i/o that i suspect will play nicer with the stream functions.

things i've been testing as i go:

• dialect/dcc: not sure if this actually needs any tests? all you've got for irc is the message parsing and dcc, uh, doesn't do that. it connects, it receives, it sends
• dialect/irc: ctcp parsing (regular PRIVMSG bookended by \x01)
• plugins/ctcp: responds appropriately to standard ctcp commands (basically, VERSION, PING, TIME). ~~tbh the plugin should really include a CLIENTINFO (listing/explaining the ctcp commands it knows), but i don't know enough about python reflection to do that without keeping track of things manually. i'll look into it~~ done
• plugins/lserv:
  • correctly builds file list, either from root directory or from textfile (one path per line). list should include only valid, visible files of specified types, none of which share a filename.
  • correctly searches file list
  • in lieu of actually sending files on request, correctly reports full path of requested file
  • handles various malformed inputs (bad list file, missing files, bad/no-result search terms/requests) gracefully

[foghawk]

the transfers, they work. there's a lot of stuff to clean up still—i think the next big thing would be persistent storage for proper config—but if i wanted i could be running a working listserv right now. ^o.o^

dcc chat still doesn't work (sends only do because they don't actually use the event loop), and i haven't implemented receives or resumes. i might move the dcc stuff into its own plugin; not sure whether that would be neater.