Date: Tue, 2 Jun 1998 15:26:22 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: configfile_t.param
In-Reply-To: <35744E11.DDF258FB@chpc.utah.edu>
Message-ID: <Pine.LNX.3.96dg4.980602151840.1565G-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Tue, 2 Jun 1998, Lou Langholtz wrote:

> Dean Gaudet wrote:
> 
> > On Mon, 1 Jun 1998, Lou Langholtz wrote:
> >
> > > It seems like we're loosing something here that we dont want to lose
> > > though. With all the hiding we should at least leave behind some
> > > method pointers with which we can get info on the configuration
> > > "objects" such as their type, and owner.
> >
> > Owner makes no sense in many contexts.
> 
> That doesn't have to be the case. I think we should take a more empowering
> direction with directory based config "objects" and strengthen there tie to
> ACL info in whatever underlying form we can get it.

No, you are missing the point.  ANY module can generate commands IN ANY
WAY IT CHOOSES.  It need only fill in the configfile_t structure and call
srm_command_loop.  mod_perl does this.  It allows folks to generate config
files as the output of a perl script.  There is no concept of owner here.
The commands can come from a database, they can come from a file, they
can come from anywhere.  There is not necessarily a concept of owner,
ACL, or anything to tie it to.

> I'll call this worse then how I was trying to do it. It doesn't give me anyway
> to delegate authority to subtree's of content to other users without giving them
> their own virtual web server.

No it doesn't require a virtual web server, just generalize what I said.

    mapuser /~([^/]*)($|/)	$1
    mapuser /foobar($|/)	foouser
    mapuser /blah($|/)		blahuser

You've just said that you delegate subtrees to users.  There is obviously
some mapping from urls to users.

Dean