Re: Storing partial responses

From: Robert Collins <robert.collins@dont-contact.us>
Date: Wed, 13 Dec 2000 12:13:24 +1100

----- Original Message -----
From: "Brian Degenhardt" <bmd@mp3.com>
To: <squid-dev@squid-cache.org>
Sent: Wednesday, December 13, 2000 8:40 AM
Subject: Re: Storing partial responses

> Ooh... that would be great for my needs (mp3 streaming). I'd like to help
> as much as possible although my knowledge about the squid source is still
> limited. Here's my 0.02:
>
> This would be really nice to augment quick_abort such that if the client
> drops connection half way through the transfer, the object can be cached as
> a partial response.
>
> As for the per-FS vs. meta-level support, I'm going to cast my vote on the
> per-FS side. Here's my scenario why: Perhaps people could write
> filesystems that were tuned towards different frequencies of partial
> requests. If the all-in-one object solution is good for one load, versus
> the one-object-per-segment, users then have a choice.
>
> Anyways, I'm willing to help where I can.
> cheers
>
> -bmd

quick_abort is one of the cases I want to address later on. It becomes trivial once we are able to combine responses. In fact in
that situation quick_abort could go out the window. We abort in every case, and are able to cache what we have retrieved. Maybe it
should stay... that's a discussion point down the track.

I think the callback suggestion I just posted in response to an earlier mail may solve your optimisation interests.. what do you
think?

Rob
Received on Tue Dec 12 2000 - 18:04:48 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:03 MST