Index: ossp-pkg/sio/al_todo.txt
RCS File: /v/ossp/cvs/ossp-pkg/sio/Attic/al_todo.txt,v
co -q -kk -p'1.1' '/v/ossp/cvs/ossp-pkg/sio/Attic/al_todo.txt,v' | diff -u /dev/null - -L'ossp-pkg/sio/al_todo.txt' 2>/dev/null
--- ossp-pkg/sio/al_todo.txt
+++ -	2024-05-19 11:06:49.294060724 +0200
@@ -0,0 +1,76 @@
+
+o rse: memory chunk maintainance
+  A piece of memory usually has the following 4 attributes which fully
+  describe it:
+
+  memory location: <pointer,length,size,refcount>
+  memory type:     STACK|HEAP|SHMEM|CUSTOM
+  memory scope:    LOAN|GIFT|[COPY]
+  memory access:   READ_ONLY|READ_WRITE
+
+  With the current al_chunk_t/al_buffer_t such a description is only
+  partly possible, although IMHO (after efficiency) this flexibility in
+  describing arbitrary memory chunks has to be #1 priority.
+
+  Currently only al_attach_buffer() allows insertion of externally
+  provided memory chunks. But these then have to be malloc(3)'ed and
+  are not allowed to be allocated differently. For this the CUSTOM type
+  would allow arbitrary memory chunks to be specified for an application
+  provided destruction callback exists.
+
+o rse: al.pod, DESCRIPTION:
+  perhaps add the buzzwords "zero-copy" and "efficient" somewhere just
+  to make sure people recognize that OSSP al is not "just another
+  trivial buffer library" ;)
+  
+o rse: al.pod, al_attach_buffer:
+  scope still does not say anything about the content, i.e., is it
+  allowed that the application still changes the content (as long as the
+  size does not change)?
+
+o rse: recommended renamings: 
+  public:
+    al_txalloc     -> al_tx_create
+    al_txfree      -> al_tx_destroy
+    al_traverse    -> al_traverse_start
+    al_traverse_cb -> al_apply
+  private:
+    new_buffer     -> buffer_new
+    dispose_buffer -> buffer_dispose
+    make_buffer    -> buffer_make
+    new_chunk      -> chunk_new
+    split_chunk    -> chunk_split
+    dispose_chunk  -> chunk_dispose
+
+o thl: sanity checks and return of AL_ERR_ARG
+
+o thl: Es fehlt eine al_configure() call mit dem man die al_memops_t
+  beeinflussen kann.
+
+o thl: Beim splicen entstehen shared buffers und deren bisherige Behandlung
+  ist rudimentaer, sorgt aber bereits fuer merklich Overhead usecount
+  in al_buffer_t). Das transferieren von Teilen solcher shared buffer
+  von einer al in eine andere ist derzeit ein Limit der Library.
+  Ein versehentliches anhaengen von Daten in anscheinend freie
+  Bufferbereiche, die aber doch von anderen Chunks genutzt werden,
+  wird derzeit schlicht durch Totalverweigerung der Nutzung von
+  evtl. freien Bufferbereichen bei shared buffers verhindert, indem
+  AL_CHUNK_RESERVE() einfach immer "null Platz" fuer shared buffer
+  (usecount > 1) zurueckgibt. Aehnliches gilt fuer das gift/loan
+  Verhalten, wegen al_attach_buffer() muss extra ein freemem flag
+  mitgescheift werden. Aber es wird gemacht und
+  funktioniert und ich wuesste auch keinen besseren Weg.
+ 
+o thl: Es ist weder in der Doku noch im Code beruecksichtigt, dass
+  die Assembly List zwischen al_traverse() und al_txfree() nicht
+  veraendert werden darf. Ist auch nicht ganz so einfach zu erklaeren,
+  denn veraendern heisst z.B. splicen. Appenden und prependen stoert
+  wohl nicht. Es gehen aber die waehrend des traversals dazugekommenen
+  Daten dem al_traverse_next() durch die Lappen, da die Datenmenge beim
+  al_traverse() berechnet wird.
+ 
+o rse: the library is not threadsafe nor even reentrant because there
+  are two static variables: alc_freelist, alc_freecount.
+
+o rse: the list.h macros lack a common prefix.
+