On Thu, Feb 22, 2001, Robert Collins wrote:
> What smarts in particular?
>
> I think the only range smarts in the
> * http client side code should be decoding range requests & creating
> single and multi range responses.
> * http server side code should be converting a generic range request to
> an upstream http range request, and converting http range responses to
> generic responses
> * likewise for the ftp server side code.
>
> I have a signficant chunk of this done in rbcollins_filters.
>
> >From what Henrik and I were bouncing around last week, we need to build
> up the intermediary outside the store, and get the store to support the
> generic concepts.
>
> If you are preparing to modify the store code support range data and
> headers as metadata then go for it. I'm getting ready to pick up the
> gauntlet for putting an intermediary together for the content_processing
> branch. (rbcollins_filters was turning into a hack job because I was
> working around the design issue..
>
The plan in my mind is to genericify the http server/client code enough to
support stuff like the TE and range requests through .. hrm. I guess what
you're doing.
I'm *aiming* towards ripping out storeClientCopy() and replacing it
with the opposite of storeAppend(). THe header parsing and range request
code were the two places I saw the obvious non-linear store client
accesses.
When I've tracked down any remaining ones I can continue reworking
the server/client data flows and then move on to sepearating the
header part from the data(body) part.
We're assuming here that each object will have a "header" part and a
"body" part, right ? This would be a nice time to tell me.
:-)
Adrian
Received on Wed Feb 21 2001 - 13:57:57 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:33 MST