httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject RE: Anywhere to go for a summmary of I/O filtering?
Date Mon, 24 Jul 2000 18:45:11 GMT

> Then we simply have VHostAsUser joe and VHostAsGroup webauthors
> properties going?  What about passwords, I assume the issue is 
> mute under unix?  And I'm assuming we aren't discussing running
> as the client/user, only the author.

We don't care about passwords.  The superuser always has access to change
to any other user on Unix.  I can't parse the last sentance, sorry.  :-)

> And are we certain that the virtualhost is sufficient?  I'm picturing, as
> a commerce administrator, that I have a group of administration scripts
> in a common share-bin folder that all should run as user isp_common,
> while their folders can all use their own id's.  The individual web admins
> have no permissions to the common cgi (they can't hack them), while they
> still have cgi-bin to play their own games.

I said VirtualHost, but it is really on a per-child basis.  I can't see
any other way to do this, and with tweaking the user and groups properly,
I think we can accomplish what you are discussing above.

> That's fine.  Forewarn and forearm module authors that filtering is subject
> to overhaul when async is implemented in 3.0 ...

I don't think any of us mind breaking all sorts of modules with major
releases, we just don't want to break them with minor releases.

> What 3.0 major feature did you have in mind when you suggested that
> async is a feature for 4.0?

I always expect new things to crop up.  Currently, I think 3.0 will be
async, but hey, you never know.  :-)

>   1) async may become a major consideration for authors/administrators when
>      it comes to choosing their web server in 2002, if it's not already.
> 
>   2) async may blow our filters design out of the water if we don't bear it
>      some consideration (not _implementation_, only _design_) as we create
>      the filter api.  I don't want to give the authors in 2002 the choice
>      between rewriting their module for Apache and rewriting for another
>      platform.  If we bear it in mind, we can avoid big rewrites (unless
>      they want to fully exploit async, which is a different issue.)
> 
> If we design async, and then stub it for filters, we can keep moving and 
> no code will be harmed in the production.  When we are ready to expose it,
> then we can revamp the server.  As it is, I'm reviewing mod_isapi to fully
> implement the API, but emulate async for authors so they aren't coding 
> twice, and for admins who aren't interested in arguing with the coder.

Cool.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message