httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: Moving some files around?
Date Wed, 24 Nov 2004 04:37:15 GMT
--On Tuesday, November 23, 2004 6:06 PM -0600 "William A. Rowe, Jr." 
<wrowe@rowe-clan.net> wrote:

>> server/core.c: the core_input/output_filter->modules/filters/core.c *or*
>>                                            server/core_filters.c
>>              (server/core.c is 150k.  Yikes!)\
>
> Sounds like multiple files to me.  Some of those are tied with...
>
>> server/request.c:
>> ap_directory_walk/ap_location_walk/ap_file_walk->server/walk.c
>
> leave location_walk - it has NOTHING to do with files.
>
> The directory/file walk corresponds to the core output filter.

Really?  Why would core_output_filter correspond to a file?  I'm not seeing 
the connection there.

Should we just leave ap_location_walk in server/request.c?  Although, I can't 
see why that makes much sense.

> Is it time to create
>
> modules/
>   storage/
>     filesystem/
>     [sql/]
>     [zip/]
>
> etc for different storage managers?

Perhaps.  I know we've talked about re-abstracting the backend layer.  Now 
that we have a decent SCM system, we can really play around with this without 
fear of CVS screwing things up.  =)

> Any walks.c / handler.c / etc would be associated to one specific
> backend manager.

*nod*

>> modules/http/http_protocol.c: ap_http_filter->modules/http/http_filter.c
>
> yup
>
>> ap_http_header_filter->modules/http/http_filter.c
>
> hmmm.  Do we want to?  or do we want to combine into one source?

We could put it into http_header_filter.c (or header_filter.c) - but that 
seems a bit overkill.

>> ap_byterange_filter->modules/http/byterange_filter.c
>
> urp.  I'm not 100% certain we want the byterange filter in the
> same context as the http protocol.  Would be -so- nice to abstract
> this so it was generic to potentially multiple protocols which all
> needed support for partial results by range.

It has a lot of HTTP specific things in it - i.e. how to parse the ranges and 
indicate the ranges.  So, as it's written right now, I believe that, yes, it's 
very HTTP-specific.

>> modules/http/http_core.c: chunk_filter->modules/http/chunk_filter.c
>
> Chunking - most http.  Good call.

If I don't get any complaints, I'll try to tackle the re-org where we have 
consensus this weekend.  And leave those that we're unsure of for later 
discussion.  -- justin

Mime
View raw message