Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@jakarta.apache.org Received: (qmail 36659 invoked by uid 500); 2 Oct 2001 15:57:18 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: "Avalon Development" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 36617 invoked from network); 2 Oct 2001 15:57:17 -0000 Message-ID: <3BB9E408.647E4D4B@apache.org> Date: Tue, 02 Oct 2001 11:58:00 -0400 From: Berin Loritsch X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Avalon Development Subject: Re: [Vote] Namespace support for Configuration objects References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Leo Sutic wrote: > > > I don't see the usefulness of making the > > Configuration object into a DOM. > > And I am not suggesting this. I am suggesting, however, that the primitive > types one can store as values should be extended with a DOM node type. The > DOM should not be traversable via the Configuration interface. > > What I am talking about is a getValueAsDOM () method. It is the _value_ that > is the DOM node. The configuration node has no children. > > Regarding resource usage: If you do not store any DOM nodes in the > configuration the overhead is zero. If you do, you pay on a per-node basis. > That price may be high, but as we both know it is rarely paid. I still don't see what this buys you. What specific problem does this solve that cannot be solved from the Configuration interface? I still maintain that the costs associated with this approach outweigh the benefits. --------------------------------------------------------------------- To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: avalon-dev-help@jakarta.apache.org