httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: configfile_t.param
Date Tue, 02 Jun 1998 22:26:22 GMT
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


Mime
View raw message