cvs commit: apache-2.0/docs api-middle.txt

[co...@hyperreal.org]

coar        98/08/04 05:29:39

  Added:       docs     api-middle.txt
  Log:
  	Add Simon Spero's thoughts about the API and the 'middle end'.
  
  Revision  Changes    Path
  1.1                  apache-2.0/docs/api-middle.txt
  
  Index: api-middle.txt
  ===================================================================
  Subject: 2.0: Thoughts on the Module API/Middle End
  Date: Tue, 04 Aug 1998 00:00:41 -0400
  From: Simon Spero <se...@tipper.oit.unc.edu>
  Reply-To: new-httpd@apache.org
  To: new-httpd@hyperreal.org
  
  I've been meaning to post some thoughts about the design of the module API ,
  but I've been sick and busy, so I thought I'd just throws some ideas up for
  people to rip to shreds.Sorry if a lot of this is incoherent.  I'd like to
  blame it all on voice recognition, but it's really my fault
  
  First of all, some stuff that should be non-controversial.
  
  1.  The current API is too HTTP specific, and too procedural in nature.  It
  is ill-defined, and inflexible when it comes to adding extra functions.  It
  is very hard to predict how modules from different developers will interact
  with each other, or two used to modules providing the same type of service
  at the same time (for example, using two different authentication modules to
  get user information from two different places).
  
  2.
  
  Back-end vs. middle-end, objects vs. names.
  
   this may be controversial, I like to think of the things that are managed
  by the back end of the server as being objects; these objects may have
  state, provided by a filesystem or a database, and can be accessed by
  invoking many different methods.  The implementation of these methods could
  potentially come from code provided by many different modules; it is the job
  of the middle end to work out which methods go with which object. Methods
  can be grouped together to form interfaces (like in Java or CORBA).
  
  Use different types of Interfaces.
  
  Each type of activity should be defined by a different interface; it should
  be possible to implement several different interfaces in the same module; it
  should also be possible to only implement part of an interface, with the
  remaining implementations coming from different sources.
  
  Use Late binding.
  
  Interfaces should be flexible and  late bound; module should only provide a
  single symbol, which would be a standard function identifying the methods
  and interfaces provided by this module. This identification the should be
  done using strings instead of locations within structs to avoid problems
  caused by adding methods to an interface.
  
  Provide fast method invocation
  
  Method indications should be fast; on the order of a jump to a function
  pointer, instead of a linear search.  It should be possible to use this
  invocation method to provide basic services to other modules (for example,
  then might be a database interface). It should be possible to take modules
  which use a carefully limited set of system services, and automatically load
  them into the kernel, or access them from a kernel module.
  
  Object VTABLES can be pieced together at run time.
  
  The process of constructing an object might  start with name resolution;
  For example, a database based implementation of a meta- information
  interface might be bound to /.  A filesystem based implementation of the
  name resolution interface could then be bound to /files. Control of  the
  name resolution processing would then be passed in to that implementation of
  the  name resolution interface, which would do further construction of the
  object, including handling tasks like content-negotiation.  This can be
  combined with other mechanisms for locating appropriate implementations to
  use with this object.
  
  VTABLES should be mostly pre-computed.
  
   the important thing is that it should be possible to statically evaluate as
  much of the resolution process as possible to build cached vtables for the
  common-path. This could be done through a method in the name resolution
  interface which would return a list of  tuples of name prefixes and
  vtables. It should be possible to quickly combine vtables for cases where
  dynamic processing is necessary. This might involve links rather than
  copying.
  
  Method Combination Should Be Predicatable And Controllable.
  
  It should be possible to control how methods are combined.  This might
  involve e.g. making a pointer to the next function to call available to the
  invokes method, in the style of LISP or Dylan; or trying all methods until
  one succeeds, all succeed, etc. .  The main constraint is that it should be
  easy to see what sort of method combination is being used without having to
  read every single piece of code involved.
  
  Object/VTABLE  Construction Should Be Customisable
  
  The process of name resolution and method combination must be customizable
  as an interface; this allows for other types of object, in particular front
  end protocol stacks, to be implemented using the same mechanisms.
  
  -------
  Misc.
  
  All access to objects should be  mediated by a cache (the core of the
  middle-end).
  
  There should be certain types of stereotyped interfaces e.g. for objects
  that behave like files.  This allows caches to be smarter.
  
  Once in object has been resolved, it should have an object ID which can be
  used in internal caching.