Re: client-store interface

On Fri, 2003-10-31 at 09:50, Henrik Nordstrom wrote:
> 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.

Yah, not -quite- there. All it needs is for the store client to accept
writes, and the server side to write to the store client, not to the
store itself. May a 1/2 days work when I get some time.

> > 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.

Well, where possible, sure.

> > 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.

We do? For all three cases? (1.0->1.1, 1.1->1.0, 1.1->1.1). 1.1->1.0
gatewaying is the silghtly tricky one.

> > 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.

Well, nothing major has occurred. We agreed then and I think we still
do, in the large brush strokes at least.

> 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.

Hmm. I'm -not- making the broker solve the odd cases. I'm giving the
client the ability to do so, without breaking abstraction.

Rob

-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.