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.
