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>.
signature.asc
Description: This is a digitally signed message part
