TODO 
----

* enable readline compilation in monitor

* There has do been done major work on `kdvacuum' (there is no kdvacuum
  binary yet, you have to do it via kdmon ... (vacuum ...)).  When an
  object is deleted and it contains blobs, we've to make a reference in and
  blob.opl (in the blobs directory).  A vacuum may kill all unused blobs
  than in the blob directory without knowing the contains of an object.

  - we may implement 'kdvacuum' as a script (scheme).  For that implement a
    'standalone' k4-machine (simply reading from stdin or file and piping
    the code to the k4-server)

* db-reindex isn't implemented.  It has to be done in a partly C partly k4
  style.  Perhaps in away like: (db-truncate-index soandso) reread every
  object and generate index-keys.  db-truncate-index has to be done in C at
  least.

* eine Flagge einfhren, die (angeschaltet) erlaubt, auch gelschte
  Datenstze zu lesen; bzw. gelschte Datenstze werden genauso gelesen wie
  normale Datenstze; allerdings behalten sie ihre Deletemarke, so da
  Highlevel Routinen (z.B. Methoden in der Core-class) dies erst abfangen
  knnen, aber Routinen, die berblickslisten erstellen, diese Datenstze
  noch lesen knnen.

* Documentation

* compilation (p-code) von k4-Programmen vervollstndigen.  Insbesondere
  Vectoren (und externe Variablen)

* Zugriff auf externe Variablen berprfen

* export von Vectoren an frontends (genauso wie listen?)
 
* Fhre Anstelle der "cc" "hc.l" - codes Numerische Krzel ein: Ein
  Groteil der Funktionen lassen sich so kategorisieren; whrend der
  Evaluierung von Funktionsparametern kann dann gleich der Typ der
  Parameter notiert werden und so die Funktionsaufrufe mchtig beschleunigt
  werden! 

* die configuration funktionen (read_config) in daemon, server,
  etc. automatisierung, so da man nur noch read_configuration
  (CONFIG_STRUCT, ...) sagen mu.  Es ist idiotisch, da das jedesmal neu
  programmiert ist!


DATAMANAGER
-----------

Der Datamanager mu noch komplett erarbeitet werden; im Moment gibt es
lediglich die Rahmenbedingungen fr Schnittstellen in den
storagemanager-functionen (sm)

* `load-file' mu in der Lage sein, auch ber den Datamanager k4-files zu
  lesen, nur so knnen Initialisierungsdateien pro Datenbank geladen
  werden, die im Datenbankverzeichnis stehen!  (Siehe unten erweitertes
  Pfadsystem!)


ADDITIONAL FEATURES/CHANGES IN THE FUTURE
------

* Erweitertes Pfadsystem.  Lispsuchpfade knnen drei Vormate annehmen:

  "/usr/local/share/k4/xyz.k4" 	UNIX Dateisystem
  "<tcp!eliot.de!8132>xyz.k4"   Datei aus dem Standardsuchpfad eines
				Remoteservers 
  "arrow:xyz.k4"                Datei aus der Datenbank arrow
                                (Datenbankspezifischer Suchpfad)

* extrahiere aus dem Server und entsprechenden Unterfunktionen einen
  byte-compiler, damit initdatein etc. compiliert eingelesen werden knnen!

* timeout auch im API! 

* eine function vector-strip, die sicherstellt, da von jedem Element nur
  ein Vorkommen pro Vector existiert

* Tja, wenn ich mal irgendwann zuviel Lust habe: dann mache ich mir einen
  zweiten Indextypus.  Z.B. einen Blockweise orientierten Index, der den
  Vorteil htte, besonders schnell und leicht lineare Listen erzeugen zu
  knnen (z.B. fr Vorauswahlen in Menus etc.)

* Internationalisierung (Markierung der Strings in Daemon done).  Achtung
  hier gibt's noch kleine Probleme: Stelle sicher, da Stringvergleiche
  (insbesondere in den Indexroutinen) grundstzlich in einer Locale
  stattfinden, (z.B. ISO-8859-1 oder C?) Damit das ganze System trotz
  wechselnder Locales konsistent bleibt.

* APIs auch fr andere Sprachen: Objective C, C++, Scheme, elisp

* use gnu configure
