Well, I think I tend to agree in princple. I do not like the
StoreEntry/StoreClient/MemObject construct currently employed. But I do
not think we share exactly the same view.
I envision two central structures in the request processing:
a) request
b) reply
The request structure keeps the state information for the actual
request.
The reply is the return traffic and can be fed from different locations:
b1) network protocols (HTTP, FTP, Gopher, whatever)
b2) object store
b3) internally generated object (error pages, cachemgr or whatever
similar)
b4) Maybe a hot-object reply cache, but I think this belongs inside the
object store concept.
Data fetched from network (b1) are also sent to the object store for
future reference, as a form of copying while forwarding.
From your talk it seems you envision having the object store the central
point connecting everything, while I have it a little on the side of
things..
So no, I do not want to give too much intelligence to the object store
or related interfaces. Instead I'd like to view it as just an object
store.
/Henrik
Adrian Chadd wrote:
> I'm going to look at the squid-NOVM code to see how squid implemented
> everything through the FS code. I still think this is the Right Thing
> To Do with a decently intelligent fs layer/layers ..
>
> Do you have any comments? I'd like to collaspe the storeentry/
> memobject/storeiostate/storeclient into a storeclient with the
> right amount of information ..
> --
> Adrian Chadd "Programming is like sex:
> <adrian@freebsd.org> One mistake and you have to support for
> a lifetime." -- rec.humor.funny
Received on Sun Dec 17 2000 - 14:30:13 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:05 MST