Yesterday, I committed the basic infrastructure required to make DCC connections behave similarly to IRC connections. I write similarly, because DCC isn't an actual protocol: each line transmitted is assumed to be a message for the client. There's not even a basic command/response structure as with IRC.
So, what I did is interpret every DCC line as it were a private PRIVMSG message. The new code reads lines from the connection, creates a dcc-chat-privmsg-message and applies it to any registered hooks, just as we do with normal IRC messages.
Why message types? Well, some DCC clients *do* support CTCP messages. Which means that we'll be able to have different message classes after all (even though they'll all stem from the PRIVMSG super type).
So, what I did (Todone):
- Implement an abstract DCC-connection type - Implement a non-abstract DCC-CHAT-connection type - Implement a dcc-chat-message type - Implement the infrastructure to receive and dispatch dcc-chat-message class messages
Todo: - Initiate (passive) chat connection - Accept (active) chat connection - Reject (passive+active) chat connection requests - Implement chat-connection interaction functionality (ie sending messages and handling default messages).
As soon as the TODO list above has been implemented, the new DCC chat functionality only lacks active DCC initiation requests and a myriad of binary (file) transfer protocols.
Basically, usocket provides the functionality required to implement active DCC connection requests, but given that it would open a port on the initiating client, I'm not yet sure what to do there: I don't want to introduce too many security problems...
So, skipping the active connection setup first, I'm going to implement the original (DCC SEND) binary file transmission scheme, much in the same way I did with DCC CHAT.
One of the problems with DCC SEND is that it's a block-oriented protocol and at the same time it's also used for transmitting binary data, meaning normally you wouldn't want to have it call hooks, but pass the data into a stream right away. Our current scheme actually already supports that: our connections have a client -stream in which we have a 'send all input from the network here' stored. This is exactly what I'll be doing. The only thing which bothers me is that there currently is no 'this connection finished' hook or callback, but that probably fits nicely with the 'we're going to remove start/stop-background-message-handler, so write your own!' scheme, where the basic message handler is just a read-message-loop call. This could be extended with a call to, say, finish-my-dcc-file-receiving-stream on the level of the client which uses the cl-irc library.
Thanks for your attention and please send your comments if you have any!
bye,
Erik.