cvs commit: avalon-sandbox/avalon5 tabled-discussions.txt

[do...@apache.org]

donaldp     2003/04/16 01:15:46

  Added:       avalon5  tabled-discussions.txt
  Log:
  Migrate more A5 discussion points here.
  
  Revision  Changes    Path
  1.1                  avalon-sandbox/avalon5/tabled-discussions.txt
  
  Index: tabled-discussions.txt
  ===================================================================
                   TABLED DISCUSSIONS
  
  This document is to record thoughts and points of discussion
  that would otherwise dilute our efforts.  The random thoughts
  listed in here will be brought up on the list when we are done
  talking about the issues already on the table.
  
  
  COMPONENT SECURITY MODEL
  ------------------------
  Currently, there is no formal security model for Avalon or its
  containers.  I think it is an oversight that we need to
  eventually remedy.  A proper security manager would allow us
  to leverage Java's security model to throw security exceptions
  if a component tries to access an unauthorized component.
  It would also allow a security administrator to provide the
  same limitations to all components that implement a certain
  role.
  
  We need to formalize the concepts of trusted and untrusted
  systems, and sandboxing the untrusted components.  That means
  we need to make it easier to use signed components as well
  as allow us to safely try to extend other components.
  
  Another integration is the addition of encrypted configuration
  data.  Certain information like usernames and passwords are
  sensitive information that we don't want to trust the OS access
  restriction model to protect.  There are so many ways of
  getting around that, and so many broken OS's where that
  protection is not trustworthy.
  
  
  CONFIGURATION MANAGER
  ---------------------
  We need a central configuration repository.  Its whole
  responsibility is to check to see if the source configuration
  has been altered, and to notify the container when it has.
  At that time, the container can reconfigure all the components
  at run time.  The contracts are between the container and
  the Configuration manager--not the individual components.
  We also need a way of storing any runtime changes to a
  component's configuration so that we can reinitialize ourselves
  properly the next time.
  
  
  META / INFO MODEL
  -----------------
  We need a model to represent component metadata. Some ideas on
  this have been codified in the containerkit, info, meta and
  xfc modules. See there for more information.
  It would be beneficial to share as much of any such model across
  different containers as possible to make component portability
  easy.
  
  
  ONE CONTAINER TO RULE THEM ALL
  ------------------------------
  There has been (and probably always will be) talk about creating
  a single container that can take on the roles of all current
  ones. There's also been talk about creating a "reference
  implementation" of a container. If we were to succeed in this it
  would make things more transparent for our users.
  
  
  AVALON 5
  --------
  There was talk about and a proposal about a new non-backwards-
  compatible version of avalon framework under the name "avalon 5";
  there's a proposal on this in the avalon cvs attic.
  Mostly this would involve small changes only. Hence it isn't
  really neccessary and has been put on hold indefinately.
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org