Index: ossp-pkg/l2/TODO
RCS File: /v/ossp/cvs/ossp-pkg/l2/TODO,v
rcsdiff -q -kk '-r1.16' '-r1.17' -u '/v/ossp/cvs/ossp-pkg/l2/TODO,v' 2>/dev/null
--- TODO	2001/09/11 10:17:23	1.16
+++ TODO	2001/09/11 12:32:02	1.17
@@ -2,15 +2,6 @@
 OSSP L2
 =======
 
-Idea:
-l2_handler_t:
-   - function pointers
-   - sizeof(handler struct)
-   - table of config callsbacks
-     which use offsetof into handler struct
-Auf diese Weise ist l2_channel_setparams aus API
-draussen und..
-
 RSE:
 - channel API cleanup: open semantics
 - bind and udp parameters in socket channel
@@ -22,38 +13,51 @@
 - l2tool [addr:]port
 - autoflush via shared memory and sub-process?
 
-Timeplan
---------
+ISSUES
+------
 
-o M1 
-  - fixed C API
-  - established build environment
-o M2
-  - implemented C API
-  - fixed C++ API
-o M3
-  - implemented C++ API
-  - documented C API
-  - documented C++ API
-  - release version 0.9.0
-o M4
-  - release version 1.0.0
+o hook_write's should perhaps receive a nul-termined string
+  instead of buf+size, because syslog else has to re-buffer it
+  in order to append the nul terminator character.
 
-ATTENTION
----------
+o Stream Members: channels static array
+  - consider dynamic
 
-o hook_write's should perhaps receive a nul-termined string
-  instead of buf+size, because syslog else has to re-buffer it.
+o buffer
+  user needs to know how a buffer object behaves in
+  relation to up/downstream channels. When does it
+  pass its data to the next channel, when does it
+  erase, what happens to its data when it is over
+  written or flushed...
+
+o syslog
+  many options need docu, and we should mention to
+  the user that more info is found in the man page
+  for syslog(), because after all that is what is
+  doing all the work in our implementation. Also,
+  can we really properly document these features
+  if they change from one system's syslog to the next?
 
-QUESTIONS
----------
+o errors
+  when a channel fails during an operation, how
+  does it report this? How should a user interpret
+  the error message or other data? Do we need more
+  accurate or detailed error messages in the channel
+  code? When a channel fails, does it continue
+  passing data on to downstream channels? Is it
+  corrupt data?
 
-o Should the following line copy the string or just use the reference?
-    L2_PARAM_SET(pa[0], ident,   CHARPTR,  &cfg->pszIdent);
+o Syslog Kanal
+  - Trim down to what will be used, right now the
+    channel supports ALL functionality through syslog(3)
 
 BRAINSTORMING
 -------------
 
+Braindump:
+- debugging is special case of logging
+- tracing is special case of debugging
+
 Channel Handler Configuration:
 o l2_handler_null
   - no configuration at all
@@ -91,44 +95,6 @@
   - write() must implicitly flush() when incoming
     data is larger than remaining buffer capacity
 
-Stream Members:
-o channels static array
-  - consider dynamic
-
-Documentation:
-o buffer
-    user needs to know how a buffer object behaves in
-    relation to up/downstream channels. When does it
-    pass its data to the next channel, when does it
-    erase, what happens to its data when it is over
-    written or flushed...
-
-o syslog
-    many options need docu, and we should mention to
-    the user that more info is found in the man page
-    for syslog(), because after all that is what is
-    doing all the work in our implementation. Also,
-    can we really properly document these features
-    if they change from one system's syslog to the next?
-
-o errors
-    when a channel fails during an operation, how
-    does it report this? How should a user interpret
-    the error message or other data? Do we need more
-    accurate or detailed error messages in the channel
-    code? When a channel fails, does it continue
-    passing data on to downstream channels? Is it
-    corrupt data?
-
-Braindump:
-- debugging is special case of logging
-- tracing is special case of debugging
-
-Kanalen:
-o Syslog Kanal
-  - Trim down to what will be used, right now the
-    channel supports ALL functionality through syslog(3)
-
 License:
 - ISC/MIT/BSD