TODO (6621B)
1 - when reading an input, determining whether it's a command or not should be 2 done first, to queue commands that do not apply to a channel (in particular 3 join) into a special general channel 4 5 - certificate check seems broken (rejects a valid certificate), why? 6 7 - missing commands: /whois /list 8 => can be sent with irc_send_raw, but how does one get the reply, is it an 9 event? should replies be displayed in a specific "server" buffer? 10 11 fix existing problems with test cases 12 13 - when connections to 6667 are dropped, irctk cannot start 14 ("Illegal operation for this state") 15 - check that if connection dies (e.g., server dies), incoming messages are 16 correctly buffered and we do not get "Illegal operation for this state when 17 interpreting" 18 (testing it seems that currently talking when server is down makes irctk quit, 19 and talking when server goes down and then up makes it reconnect but loses the 20 message) 21 22 http://tools.ietf.org/html/rfc2812 23 IRC messages are always lines of characters terminated with a CR-LF 24 (Carriage Return - Line Feed) pair, and these messages SHALL NOT 25 exceed 512 characters in length, counting all characters including 26 the trailing CR-LF. 27 (thanks: Marc Jeanmougin) 28 29 - fix track.sh and order2.sh 30 - what happens when we talk but are actually not connected? 31 32 later: 33 - exit when killed, advertising the signal 34 - use notices and errors 35 - look into sirc-2.211/ssfe.c 36 - ipv6 support 37 38 tracking: 39 - use user list given when joining 40 - handle multiple addresses 41 - use output_nick in channel names 42 43 tests: 44 - last active by default (timing) 45 - rename-tracking, unique-names 46 - what is being tested in sync.sh ? 47 48 other: 49 - have a flag to throttle the global rate of things sent to the server (global, 50 not by channel) to avoid getting kicked due to excess flood 51 52 Future features: 53 54 irc_color_convert_to_mirc 55 56 DCC 57 58 other: 59 - don't block if stdout block, use a fifo with a thread 60 61 /* 62 {"default-last-active-delimited", 'd', 0, 0, 63 "Like -a but messages are read in atomic groups starting and ending with a blank line." 64 CHANNEL_SELECTION}, // TODO 65 {"default-last-active-delimited-queued", 'D', 0, 0, 66 "Like -d but require one message group for each outputted message." 67 CHANNEL_SELECTION}, // TODO 68 */ 69 70 * --default-last-active-delimited 71 72 WARNING: This option is not yet implemented. 73 74 Messages with no destination will be sent to the last active channel, like with 75 --default-last-active. However, if you provide a blank line, non-blank lines, 76 and a blank line, the non-blank lines are treated as an atomic message group 77 which will be sent to the last active channel at the moment when the initial 78 blank line was read by irctk. 79 80 This is useful if you want to answer a message in a way which can potentially 81 take time. Whenever you receive a message you want to reply to, output a blank 82 line. Then, perform computations, provide the actual message, and finish with a 83 blank line. In that way, the reply will go in the proper channel. The downside 84 of this is that you will not be able to answer on the right channel for any 85 messages which occur while you are managing a query. For this case, another 86 option is available. 87 88 * --default-last-active-delimited-queued 89 90 WARNING: This option is not yet implemented. 91 92 For every message that it produces on stdout, irctk expects to read on stdin a 93 message group (blank line, non-blank lines (possibly 0), blank line) which will 94 be sent to the channel of the incoming message. Lines which occur outside of a 95 block are sent to the last active channel at the time when they are read. 96 97 This option allows you to process each incoming message as a request, and output 98 a delimited answer to this request which will be routed to the right channel. 99 The only limitation is that requests cannot be processed in parallel -- if this 100 is an issue, consider forgetting about the channel inference options and always 101 indicate the destination channel according to your own complicated logic. 102 103 * --reply 104 105 This option is useful to write bots: whenever a destination channel is inferred, 106 a destination nick is inferred, which is equal to the nick of the person who 107 said the message. All outgoing messages are prefixed with this nick. Note: with 108 --default-last-active-delimited and --default-last-active-delimited-queued, this 109 option only applies to the message groups, not to content outside groups. 110 111 * --default-last-active-delimited 112 113 WARNING: This option is not yet implemented. 114 115 Messages with no destination will be sent to the last active channel, like with 116 --default-last-active. However, if you provide a blank line, non-blank lines, 117 and a blank line, the non-blank lines are treated as an atomic message group 118 which will be sent to the last active channel at the moment when the initial 119 blank line was read by irctk. 120 121 This is useful if you want to answer a message in a way which can potentially 122 take time. Whenever you receive a message you want to reply to, output a blank 123 line. Then, perform computations, provide the actual message, and finish with a 124 blank line. In that way, the reply will go in the proper channel. The downside 125 of this is that you will not be able to answer on the right channel for any 126 messages which occur while you are managing a query. For this case, another 127 option is available. 128 129 * --default-last-active-delimited-queued 130 131 WARNING: This option is not yet implemented. 132 133 For every message that it produces on stdout, irctk expects to read on stdin a 134 message group (blank line, non-blank lines (possibly 0), blank line) which will 135 be sent to the channel of the incoming message. Lines which occur outside of a 136 block are sent to the last active channel at the time when they are read. 137 138 This option allows you to process each incoming message as a request, and output 139 a delimited answer to this request which will be routed to the right channel. 140 The only limitation is that requests cannot be processed in parallel -- if this 141 is an issue, consider forgetting about the channel inference options and always 142 indicate the destination channel according to your own complicated logic. 143 144 * --reply 145 146 This option is useful to write bots: whenever a destination channel is inferred, 147 a destination nick is inferred, which is equal to the nick of the person who 148 said the message. All outgoing messages are prefixed with this nick. Note: with 149 --default-last-active-delimited and --default-last-active-delimited-queued, this 150 option only applies to the message groups, not to content outside groups. 151 152 si on est full unbuffered, attendre qu'un write sur stdout ait fini de 153 bloquer avant de considérer que le write a été vu pour last_nick et autres