$Id: TODO,v 1.8 2001/01/07 23:53:15 aigan Exp $

Prototype case one: Address register

DONE  - Add properties
DONE  - View all properties for person
DONE  - Create a web HTML interface to register
DONE  - Remove/change statements
DONE  --- (alpha 1)
DONE  - Context wrappers for objects
DONE  - Selections for searches
DONE  - minimal arc(), arc_obj() and rev_type()
DONE  - list() and li()
DONE  --- (alpha 2)
DONE  - c/s architecture
DONE  - callbacks to updated cache on changes in the source
DONE  --- (alpha 3)
DONE  - Reuse DB connections
DONE  - Session metadata
DONE  - User identification
DONE  --- (alpha 4)
      - Model authority
      - authenticated change/delete
      --- (alpha 5)
      - minimal SDL general presentation framework
      - minimal inference/translation rules
      --- (alpha 6)
      - Generalize prototyp application
      - Set official schema URIs
      - Test suite
      --- (beta 1)


Post 1.0:

 - Adaptive internal data storage
 - Query optimization engine
 - HTTP interface
 - XML import/export interface
 - translation rules
 - Complete SDL
 - DSIG
 - Function / property equality
 - Advanced cache control
 - Inter-service communication
 - ...



There are still tons of things to include and optimize.

* The core often want's to list the types of a resource, ordered by
  their place in the class heiarcy.  This has been done by giving
  every class a LS:level property.  That should go in the core to
  avoid a full blown "search request" for every pair comparsion in the
  sorting of the classes.  

* A general solution will have to be developed for sorted lists in
  general.  Lists are represented by containers.  The iteration
  through those containers will be done in a specified order.

* I haven't yet created the code for using namespaces.  The context
  will have a list of namespaces and those will be used while viewing
  the resources.  This will for example be used by the desig()
  function.

* A request for returning a list of resources will normaly do so by
  returning a Selection container resource.  This gives a lot of
  internal overhead.  Some shortcuts is and will be created.  But more
  important is that a normal selection doesn't have to be stored in
  the cache.  This can easily be fixed by creating a new constructor
  for those types of temporary resources.

* The server should be avare of its memory consumption.  Old or little
  used cached resoruces should be expired.

* The DBI interface stores the URI of resources it doesn't have to
  store.  A cleanup could be done of nonreferenced URIs.  But it would
  be nicer if the interface wouldn't create those records in the first
  place.

* Most of the described API hasn't been created.  The API will give a
  session object methods with the name of the property for accessing
  that property.  But those names are a short name for the full URI.
  And those shortcuts must be specified for each session or context.
  That means another level of indirection.  I would like to avoid
  that...