irctk

libircclient binding for scripts
git clone https://a3nm.net/git/irctk/
Log | Files | Refs | README

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