Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Message-ID: <088601c3a596$30702840$8f8b1f43@tsws1>
From: "Adam R. B. Jack" <ajack@trysybase.com>
To: <repository@apache.org>, <jvanzyl@maven.org>
References: <BAY1-F1315T7j8cwwbD0000c56d@hotmail.com>
 <052301c3a542$af801fe0$8f8b1f43@tsws1>  <3FABCCFA.8030004@apache.org>
 <1068225434.18114.83.camel@localhost.localdomain>
 <3FAC02D2.4070708@apache.org>
 <1068239309.18114.187.camel@localhost.localdomain>
 <3FAC1AF3.7060805@apache.org>
 <1068253059.18114.212.camel@localhost.localdomain>
Subject: Re: Scope/Phasing
Date: Fri, 7 Nov 2003 18:18:09 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> It's really not that much more than that.
> Sophisticated systems that are reliable are built upon simplicity not
> complexity

I agree. I'd like to think of what we are doing as laying out a simple file
system, and later building services that index/query. Compare this to
/cvsroot, cvs protocol (clients to a remote server), then viewcvs (a
'server' behind HTTP, implemented as a client to CVS). Each built on top of
the other, nice and simple, nice and powerful at each level. Compare this to
a www site w/ search, text indexing, whatever. Each layer is independent,
independently specified, and independently useful.

I feel that if we nailed down the first, we can build the second and third
server side, as and when need arises. Metadata-less at the lowest level,
optionally richer as on moves up. Simplicity is the key at each level, I
completely agree w/ Jason there.

Nick is right ... we need to specify based upon requirements, and code
(whose-ever) can follow.

regards

Adam