You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Havard <br...@kheldar.apana.org.au> on 2000/01/09 08:25:19 UTC
Re: cvs commit: apache-2.0/src/modules/standard mod_actions.c mod_asis.c mod_autoindex.c mod_cgi.c mod_dir.c mod_include.c mod_mime.c mod_negotiation.c mod_userdir.c
On 6 Jan 2000 14:43:52 -0000, rbb@hyperreal.org wrote:
>rbb 00/01/06 06:43:51
>
> Modified: src/include httpd.h
> src/lib/apr/file_io/unix fileacc.c filedup.c fileio.h
> filestat.c open.c pipe.c readwrite.c
> src/lib/apr/include apr_file_io.h
> src/lib/apr/test ab_apr.c testmmap.c
> src/main http_config.c http_core.c http_log.c
> http_protocol.c http_request.c util.c
> src/modules/standard mod_actions.c mod_asis.c
> mod_autoindex.c mod_cgi.c mod_dir.c mod_include.c
> mod_mime.c mod_negotiation.c mod_userdir.c
> Log:
> Separate the stat structure from the file structure and use ap_stat and
> ap_getfileinfo in apache.
>
> Revision Changes Path
[...]
> 1.26 +20 -9 apache-2.0/src/lib/apr/include/apr_file_io.h
>
> Index: apr_file_io.h
> ===================================================================
> RCS file: /home/cvs/apache-2.0/src/lib/apr/include/apr_file_io.h,v
> retrieving revision 1.25
> retrieving revision 1.26
> diff -u -r1.25 -r1.26
> --- apr_file_io.h 2000/01/04 19:00:44 1.25
> +++ apr_file_io.h 2000/01/06 14:43:19 1.26
[...]
> -ap_status_t ap_get_filetype(ap_filetype_e *, ap_file_t *);
> +ap_status_t ap_get_filetype(ap_filetype_e *, ap_fileperms_t);
This API change is not right. It assumes a file's type can be derived from a
ap_fileperms_t which is not true for all platforms, probably only true for
unix. The OS/2 implementation of ap_get_filetype() needs the file handle.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_actions.c mod_asis.c mod_autoindex.c mod_cgi.c mod_dir.c mod_include.c mod_mime.c mod_negotiation.c mod_userdir.c
Posted by Manoj Kasichainula <ma...@io.com>.
On Tue, Mar 21, 2000 at 05:12:06PM -0800, Dean Gaudet wrote:
> On Sun, 9 Jan 2000 rbb@apache.org wrote:
>
> > 2) Merge the IOL stuff into APR types. This was discussed a while ago,
> > and there are people who don't like this idea, but it does solve this
> > problem.
>
> who doesn't like it and why?
I used to not like it, but I've changed my mind (I think :).
Re: cvs commit: apache-2.0/src/modules/standard mod_actions.c
mod_asis.c mod_autoindex.c mod_cgi.c mod_dir.c mod_include.c mod_mime.c
mod_negotiation.c mod_userdir.c
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 9 Jan 2000 rbb@apache.org wrote:
> 2) Merge the IOL stuff into APR types. This was discussed a while ago,
> and there are people who don't like this idea, but it does solve this
> problem.
who doesn't like it and why?
> 3) Re-design the IOL stuff to hide the internals a bit less.
>
> I really don't care what we do, but I see no way to redesign this code to
> fix the problem without affecting the IOL's in some big way. I'll
> probably put this off until tomorrow, because I don't really feel like
> dealing with it today.
i tried to stress a long time ago that iols were just something to get me
up and going... proof of concept. i figured that when ben demonstrated
ssl that it was "good enough" for now.
by all means, do something more complicated.
might i suggest looking at NSPR again? :) just look at what their
layering provides.
Dean
Re: cvs commit: apache-2.0/src/modules/standard mod_actions.c mod_asis.c mod_autoindex.c mod_cgi.c mod_dir.c mod_include.c mod_mime.c mod_negotiation.c mod_userdir.c
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Mon, 10 Jan 2000 07:04:17 -0500 (EST), Ryan Bloom wrote:
>
>Please, commit away. :-)
Ok, but it may take a little while to get my source tree cleaned up a bit.
I've got a few other assorted changes mixed in.
>> There's an easy way to do it, just add a filetype field to ap_finfo_t and set
>> it when doing the stat. This removes the need for ap_get_filetype()
>> altogether just like ap_get_filesize() & friends.
>>
>> This also requires that tests like "S_ISDIR(finfo.protection)" are changed to
>> "finfo.filetype == APR_DIR".
>>
>> I've already implemented this for OS/2 and have a running server using it. If
>> there are no objections I'll commit it.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_actions.c
mod_asis.c mod_autoindex.c mod_cgi.c mod_dir.c mod_include.c mod_mime.c
mod_negotiation.c mod_userdir.c
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Please, commit away. :-)
Ryan
> There's an easy way to do it, just add a filetype field to ap_finfo_t and set
> it when doing the stat. This removes the need for ap_get_filetype()
> altogether just like ap_get_filesize() & friends.
>
> This also requires that tests like "S_ISDIR(finfo.protection)" are changed to
> "finfo.filetype == APR_DIR".
>
> I've already implemented this for OS/2 and have a running server using it. If
> there are no objections I'll commit it.
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: cvs commit: apache-2.0/src/modules/standard mod_actions.c mod_asis.c mod_autoindex.c mod_cgi.c mod_dir.c mod_include.c mod_mime.c mod_negotiation.c mod_userdir.c
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Sun, 9 Jan 2000 16:07:17 -0500 (EST), rbb@apache.org wrote:
>
>> > -ap_status_t ap_get_filetype(ap_filetype_e *, ap_file_t *);
>> > +ap_status_t ap_get_filetype(ap_filetype_e *, ap_fileperms_t);
>>
>> This API change is not right. It assumes a file's type can be derived from a
>> ap_fileperms_t which is not true for all platforms, probably only true for
>> unix. The OS/2 implementation of ap_get_filetype() needs the file handle.
>
>This is actually harder to do than I had hoped. The problem is that
>Apache no longer stores a copy of the file handle in the request
>structure. Now, we store a pointer to an IOL, which if you follow far
>enough, you can resolve to a file handle. This is what caused me to make
>this change originally. I think we basically have a few options.
>
>1) Add a ap_iol_filetype which returns the file type from the IOL.
>
>2) Merge the IOL stuff into APR types. This was discussed a while ago,
>and there are people who don't like this idea, but it does solve this
>problem.
>
>3) Re-design the IOL stuff to hide the internals a bit less.
>
>I really don't care what we do, but I see no way to redesign this code to
>fix the problem without affecting the IOL's in some big way. I'll
>probably put this off until tomorrow, because I don't really feel like
>dealing with it today.
There's an easy way to do it, just add a filetype field to ap_finfo_t and set
it when doing the stat. This removes the need for ap_get_filetype()
altogether just like ap_get_filesize() & friends.
This also requires that tests like "S_ISDIR(finfo.protection)" are changed to
"finfo.filetype == APR_DIR".
I've already implemented this for OS/2 and have a running server using it. If
there are no objections I'll commit it.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_actions.c
mod_asis.c mod_autoindex.c mod_cgi.c mod_dir.c mod_include.c mod_mime.c
mod_negotiation.c mod_userdir.c
Posted by rb...@apache.org.
> > -ap_status_t ap_get_filetype(ap_filetype_e *, ap_file_t *);
> > +ap_status_t ap_get_filetype(ap_filetype_e *, ap_fileperms_t);
>
> This API change is not right. It assumes a file's type can be derived from a
> ap_fileperms_t which is not true for all platforms, probably only true for
> unix. The OS/2 implementation of ap_get_filetype() needs the file handle.
This is actually harder to do than I had hoped. The problem is that
Apache no longer stores a copy of the file handle in the request
structure. Now, we store a pointer to an IOL, which if you follow far
enough, you can resolve to a file handle. This is what caused me to make
this change originally. I think we basically have a few options.
1) Add a ap_iol_filetype which returns the file type from the IOL.
2) Merge the IOL stuff into APR types. This was discussed a while ago,
and there are people who don't like this idea, but it does solve this
problem.
3) Re-design the IOL stuff to hide the internals a bit less.
I really don't care what we do, but I see no way to redesign this code to
fix the problem without affecting the IOL's in some big way. I'll
probably put this off until tomorrow, because I don't really feel like
dealing with it today.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@ntrnet.net
6209 H Shanda Dr.
Raleigh, NC 27609 Ryan Bloom -- thinker, adventurer, artist,
writer, but mostly, friend.
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/modules/standard mod_actions.c
mod_asis.c mod_autoindex.c mod_cgi.c mod_dir.c mod_include.c mod_mime.c
mod_negotiation.c mod_userdir.c
Posted by rb...@apache.org.
> > -ap_status_t ap_get_filetype(ap_filetype_e *, ap_file_t *);
> > +ap_status_t ap_get_filetype(ap_filetype_e *, ap_fileperms_t);
>
> This API change is not right. It assumes a file's type can be derived from a
> ap_fileperms_t which is not true for all platforms, probably only true for
> unix. The OS/2 implementation of ap_get_filetype() needs the file handle.
Okay, fair enough. I'll change it back today. :)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@ntrnet.net
6209 H Shanda Dr.
Raleigh, NC 27609 Ryan Bloom -- thinker, adventurer, artist,
writer, but mostly, friend.
-------------------------------------------------------------------------------