Return-Path: 
 <dev-return-20974-apmail-avalon-dev-archive=avalon.apache.org@avalon.apache.org>
Delivered-To: apmail-avalon-dev-archive@avalon.apache.org
Received: (qmail 24714 invoked by uid 500); 8 Apr 2003 08:22:33 -0000
Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@avalon.apache.org>
List-Subscribe: <mailto:dev-subscribe@avalon.apache.org>
List-Help: <mailto:dev-help@avalon.apache.org>
List-Post: <mailto:dev@avalon.apache.org>
List-Id: "Avalon Developers List" <dev.avalon.apache.org>
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Delivered-To: mailing list dev@avalon.apache.org
Received: (qmail 24699 invoked from network); 8 Apr 2003 08:22:32 -0000
Received: from main.gmane.org (80.91.224.249)
  by daedalus.apache.org with SMTP; 8 Apr 2003 08:22:32 -0000
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 192oMH-0004Mc-00
	for <dev@avalon.apache.org>; Tue, 08 Apr 2003 10:21:33 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: dev@avalon.apache.org
Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 192oLp-0004LA-00
	for <gmane-comp-jakarta-avalon-devel@m.gmane.org>;
 Tue, 08 Apr 2003 10:21:05 +0200
From: Leo Simons <leosimons@apache.org>
Subject: Re: Verifying Meta Tags
Date: Tue, 08 Apr 2003 10:21:32 +0200
Lines: 29
Message-ID: <b6u0ph$g9e$1@main.gmane.org>
References: <3E922780.9010503@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@main.gmane.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
In-Reply-To: <3E922780.9010503@apache.org>
Sender: news <news@main.gmane.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Berin Loritsch wrote:
> It is my inderstanding that we are OK with the following tags:
> 
<snip/>
> 
> Am I misunderstanding anything?

you might be.

FWIW (like said before), there is no consensus that it makes sense at 
all to add any kind of metadata capability to fortress prior to a 1.0 
release -- I'm not "OK" with it: it delays release, it hasn't received 
enough testing, it makes the codebase fluctuate in a near-release 
stadium, it adds more baggage to support in any container which wants to 
support "all existing container setups" as you're adding a third model, 
it results in another codebase we'll have to maintain which is very 
similar to the ones in phoenix and in merlin, yet which has to 
maintained seperately. Regardless, metadata capability can be added to 
fortress later or developed seperately as an extension module, as your 
own d-haven project has so nicely shown, so this move is not obeying the 
KISS principle.

No veto from me here (as in short it is silly to veto good code on the 
basis of a roadmap), but I definately don't agree.

cheers!

- Leo



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