Reprocess JOIN command synchronously after resolving channel
[crypto.git] / TODO
diff --git a/TODO b/TODO
index 0132fb66835dddea66c67b58b17aa30bdcb77f84..5bfd5f6937d9719e6af1070d12e0d843c8b0d045 100644 (file)
--- a/TODO
+++ b/TODO
@@ -68,6 +68,15 @@ lib/silcclient, The Client Library
    never joined the channel if this happens.  What to do if message is
    received from user that hasn't been resolved/joined?
 
+ o Add the SilcStream (socket stream) from the SilcPacketStream and
+   SilcSocket from the socket stream to SilcClientConnection for easier
+   access to them for programmers.  Currently these have to be digged up
+   from the packet stream.
+
+ o Connection option that attemps to connect to remot host with various 
+   different mechanisms: UDP 706, TCP 706, TCP 80, TCP 443, UDP 7706 and
+   TCP 7706.  This is the so called hole punching mechanism.
+
  o Message ACKing support.
 
  o in /cmode and /cumode with +r, maybe the public key and private key
@@ -78,6 +87,8 @@ lib/silcclient, The Client Library
    should provide events so that application developer has a choice of
    developing the SILC app with callbacks or with events.
 
+ o Ability to recover from rekey errors, at least try to.
+
 
 Runtime library, lib/silcutil/
 ==============================
@@ -94,6 +105,14 @@ Runtime library, lib/silcutil/
 
  o silc_getopt routines
 
+ o Add silc_stream_get_root and add get_root stream operation.  It 
+   returns the root of the stream or NULL if stream doesn't have root.
+
+ o Change some stream routines (like socket stream API) to accept ANY
+   stream and use silc_stream_get_root to get the socket stream from the
+   given stream.  This will make various stream APIs more easier to use
+   when user doesn't have to dig up the correct stream.
+
  o The SILC Event signals.  Asynchronous events that can be created,
    connected to and signalled.  Either own event routines or glued into
    SilcSchedule:
@@ -149,7 +168,7 @@ Runtime library, lib/silcutil/
    This relationship would be associative only.  The schedulers are still
    independent and run independently from each other.   All schedulers
    would be linked and could be accessed from any of the schedulers.
-   It should be possible to retrieve the parent and enumate all children
+   It should be possible to retrieve the parent and enumerate all children
    from any of the schedulers.
 
    SilcSchedule silc_schedule_init(int max_tasks, void *app_context,
@@ -198,6 +217,11 @@ Runtime library, lib/silcutil/
    _ua unaligned memory allocation routines.  Remove unaligned memory
    allocation possibility. (***DONE)
 
+ o silc_stack_alloc shouldn't require multiple by 8 size argument, it 
+   should figure it out itself.
+
+ o silc_malloc et. al. to respect --with-alignment.
+
  o Add '%@' format to silc_snprintf functions.  It marks for external
    rendering function of following type:
 
@@ -217,9 +241,13 @@ Runtime library, lib/silcutil/
    }
 
    silc_snprintf(buf, sizeof(buf), "Client ID %@", id_renderer, client_id);
+   (***DONE)
 
  o Change silc_gettimeofday on Unix to use clock_gettime with REALTIME
-   clock if it is available, otherwise use gettimeofday().
+   clock if it is available, otherwise use gettimeofday(). (***DONE)
+
+ (o SilcIpAddr abstraction.  Ipv4 and Ipv6 support to the abstaction.) 
+  maybe
 
  (o Generic SilcStatus or SilcResult that includes all possible status and
     error conditions, including those of SILC protocol.  Though, the SILC
@@ -334,6 +362,8 @@ Crypto Library, lib/silccrypt/
 
  o Add ECDH support.
 
+ o AES CBC is missing proper alignment code (see silc_1_1_branch).
+
  o All cipher, hash, hmac etc. allocation routines should take their name
    in as const char * not const unsigned char *. (***DONE)
 
@@ -350,6 +380,27 @@ SILC Accelerator Library
    public key and private key operations are executed in threads. 
    (***DONE)
 
+ o Add init options to SilcAcceleratorObject as a SilcAcceleratorOption
+   structure.  Each accelerator defines the options that they support and
+   can be retrieved from the SilcAccelerator with silc_acc_get_options.
+   The format must also be machine parseable.  The structure can be of the
+   following format:
+
+       typedef struct SilcAcceleratorOptionStruct {
+         const char *option;                   /* Option name */
+         const char *display_name;             /* Option displayable name */
+         SilcParamType type;                   /* Option data format */
+       } *SilcAcceleratorOption;
+
+   For software accelerator it could be for example:
+
+   { "min_threads", "Minimum threads", SILC_PARAM_UINT32 },
+   { "max_threads", "Maximum threads", SILC_PARAM_UINT32 },
+
+   The accelerator itself doesn't have to use the option structure to
+   parse the options if not wanted.  It is defined for the caller so
+   they can learn the supported options in a well defined way.
+
  o Diffie-Hellman acceleration
 
  (o Symmetric key cryptosystem acceleration?  They are always sycnhronouos
@@ -504,10 +555,26 @@ lib/silcserver
  o Do inccoming packet processing in an own FSM thread in the
    server-threads FSM.  Same as in client library.
 
+ o Binding to other ports than 706 too.  To allow easier traversing
+   through NATs and firewalls server should bind to 80, 443 and 7706
+   by default (at least try to bind).  Connections must work normally
+   even if they were established to some other port other than 706.
+
+   Connection option that attemps to connect to remot server with various 
+   different mechanisms: UDP 706, TCP 706, TCP 80, TCP 443, UDP 7706 and
+   TCP 7706.  This is the so called hole punching mechanism.
+
+ o Ability to recover from rekey errors, at least try to.
+
  o Reference count all Silc*Entry structures.
 
  Some issues that must be kept in mind from 1.0 and 1.1 silcd's:
 
+ o The server and router software MUST work out of the box.  After 
+   installation the server must not require any configuration to run the
+   most basic working configuration.  No defining IP addresses, etc.
+   The server must work just by running it.
+
  o The SERVER_SIGNOFF notify handing is not optimal, because it'll
    cause sending of multiple SIGNOFF notify's instead of the one
    SERVER_SIGNOFF notify that the server received.  This should be