Re: client-store interface

On Fri, 31 Oct 2003, Robert Collins wrote:

> Sure. The issue I have with your design is that it makes the
> server/store drive everything which is exactly the problem we had before
> where the client side drove everything. Downgrading is esaier if the
> client side can drive it's needs. Teaching the store about freeable
> ranges in random access needs to be done - in either approach.

One note:

if the store IS separated from the forwarding path then most of what I
discuss is simply a non-issue relating to the store. If the store is
separated then it is just a storage bin where cachable content is thrown
into and cache hits is read from, it is NOT part of the forwarding for
cache misses.

> Right. And where squid initiated these changes, squid should re-request
> unconditionally. IOW, no headers should be returned to the client side,
> until the required upstream requests have returned their headers and
> been compataiblity tested against the basis for the request.

I pretty much prefer to avoid even risking running into situations were we
have to reforward after getting some form of reply from the server.

> Yeah. Theres other uses for the notification - to implement the arrival
> of headers, and for the transactions needed for 1XX Continue support.

Thinking... for 100 Continue some form of notification does indeed need to
be there, but it does not need to be more than the simple fact that there
is someone asking for the request entity content. This notification path
we already have.

> Well... The broker is called 'store_client'... Its the layer for
> accessing the hot store and the cold store by the client side. The
> improvements that could be made are to make store writes occur through a
> store client too. The store_client has very little knowledge of store
> internals now, and when finished will be just a broker.

Good, but very confusing terminology.

I did outline pretty much what I wanted in terms of design some year ago
or so. Can not say I have seen anything which had made me change my mind
since then.

But I disagree that it should be the broker who tries to solve the "odd"
cases. These belongs in the server side processing as far as possible. The
server-side has far better knowledge of what can be done within the
protocol to solve the situation.

> I have to get something in place for fixing bug 624, so It'll be what
> I've sketched out. Shouldn't be too hard to fiddle the design to fit
> whatever we agree on.

Good.

Regards
Henrik
Received on Thu Oct 30 2003 - 15:50:21 MST