Return-Path: Delivered-To: apmail-avalon-dev-archive@avalon.apache.org Received: (qmail 82915 invoked by uid 500); 27 Jun 2003 15:20:00 -0000 Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list dev@avalon.apache.org Received: (qmail 82902 invoked from network); 27 Jun 2003 15:19:59 -0000 Received: from onramp.i95.net (205.177.132.17) by daedalus.apache.org with SMTP; 27 Jun 2003 15:19:59 -0000 Received: from apache.org ([66.208.12.130]) by onramp.i95.net (8.12.9/8.12.9) with ESMTP id h5RFK1RH021929 for ; Fri, 27 Jun 2003 11:20:01 -0400 Message-ID: <3EFC60A2.6090806@apache.org> Date: Fri, 27 Jun 2003 11:20:02 -0400 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: [RT] Container Components Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N In order for us to be able to plug in different aspects to our containers, we will need some privileged information. J Aaron Farr (jaaron) outlined what these things need. It makes sense. First let's look at the feasibility, then look at how to make it work with a security model of sorts. #1) We need to provide access to component meta information #2) We need to provide access to container assembly information The question is what interface would work best for this? I would like to work with a basic extensible meta info library that is lightweight, well-tested, and can be used in all containers. We need to work with the AMTAGS proposal, and fill in any holes. IMO we should work with a Queryable interface as opposed to an object model based one. While an object model provides a certain ease of use, it is not as extensible. I am open to discussion on the matter, and hopefully there will be reams of emails when I get back.... As to the Assembly information what do we need beyond the simple component mapping? What do we want to formally represent? Also, how do we deal with components that have a lookup something like URL protocol resolution (i.e. "http" pulls up the HTTP protocol handling component and "ftp" pulls up the FTP protocol handling component)? How do we come to a middle ground with Phoenix, Merlin, and Fortress? Currently Fortress does not have any *real* notion of assembly, but it really needs it. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For additional commands, e-mail: dev-help@avalon.apache.org