Message-Id: <199607181906.OAA07528@sierra.zyzzyva.com>
To: new-httpd@hyperreal.com
Subject: Re: Let's get rid of .htaccess files :-) 
In-reply-to: dave's message of Thu, 18 Jul 1996 14:48:24 -0400.
         <Pine.GSO.3.93.960718144058.25823C-100000@newshare.newshare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 18 Jul 1996 14:06:03 -0500
From: Randy Terbush <randy@zyzzyva.com>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

> On Thu, 18 Jul 1996, Howard Fear wrote:
> 
> > But, this is exactly the problem.  There are at least two general
> > philosophies to 'webspace': the web as a filesystem, and the web
> > as an interface to files in the underlying file system. 
> 
> 	There is also a 3rd philosophy, not now prevalent in the 
> 	Internet, which is "capability based" - relating to access
> 	to information in databases.  Here, of course, a person has
> 	access to a subset of the DBMS's capabilities not specific
> 	files. 
> 
> 	We are finding also that certain types of information providers
> 	have almost no static files.  All the output is generated by 
> 	accumlating pieces from different databases, which have their
> 	own (private) view of the underlying file system.

I don't think that Apache needs to be concerned about authentication
beyond the point of your database interface. Does it?


> > We also should preserve the distinction between server configuration
> > and 'file' configuration.  The former should not only have limited
> > access, but also limited visibility.  It also, probably, causes
> > a server restart.  The second should be available to all users
> > (for their files) and shouldn't (mustn't) cause server restarts.
> 
> 	I am inclined to agree with this view, though it is thorny
> 	when you take a database view of the world (whre the database
> 	is doing much of the access control).

Again, I'm not suggesting that we take over access control for the
database. I see a time when there will be less distinction between
the two, but for now, I see Apache configuration as the issue.

> > > It would be very easy to have a separate daemon watching the
> > > conf/ for changes and sending a SIGHUP when needed.
> > 
> > I don't see the need for this.  And, I think this is a real problem
> > if you're going to let your users control the configuration of their
> > own files.  (This may not generally be the case for commercial
> > web servers, but is certainly desireable for intranets.)
> 	
> 	agreed.

I know that some people in this group allow their customers to configure
their own server/Vhost and to even send a SIGHUP to the sever after 
they make a change. My comment simply suggests one of many possible
ways to allow configuration changes by customers to be handled. With
Ben's graceful restart changes, this is even less of an issue.