I guess one of the more important points to note is that for many if not
most people, Squid is used primarily to *save* bandwidth and therefore
cost. Although the approach of "intelligent fetching" may be beneficial
for speed, it would probably not be of any benefit in terms of bandwidth
saving because guessing invariably is a risky process [you don't know for
sure if the object will be retrieved by the clients]. I personally
consider the "bandwidth saving" ideas behind squid to be of more importance.
There are client programs which, certainly under Windows, accomplish the
same task as what is being suggested. I would suggest that they may be a
better approach to use in situations where this sort of behaviour is
required. That way, the client pays the cost of the extra speed, rather
than the squid-maintainer.
In time though, when Squid is a "bug-free" piece of art, it may be worth
implementing. Perhaps an option for "bandwidth optimised" or "speed
optimised" ?
Then again, I can't write the code. There's nothing to stop someone else
going ahead with it ;)
Reuben
At Wednesday 2/06/99 04:32 AM -0400, Allen Smith wrote:
>On Jun 2, 4:24am, Henrik Nordstrom (possibly) wrote:
> > Dax Kelson wrote:
> >
> > > When a user requests a html document, the commercial box scans that html
> > > document for additional objects (mostly images) and starts retrieving
> > > those immediately. Shortly after, when the client requests those
> objects,
> > > the cache box either has them already, or is already getting them.
> > >
> > > Could this be implemented in Squid?
> >
> > Could: yes, Is: no, Given priority: very low.
>
>A minor version of this that wouldn't be nearly as hard to implement
>(I've looked at doing it myself, although it's currently pretty far
>down on my ever-growing list of tasks) would be requesting and caching
>any cachable referred object (referred via HTTP responses, not HTML
>coding).
-------------------------------------------------------------
Reuben Farrelly Sunbury, VIC 3429, Australia
Received on Wed Jun 02 1999 - 03:58:34 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:46:42 MST