>> At 17:40 9/09/99 -0700, Joe Touch wrote:
>> >A cache is a system which stores temporary copies of response messages,
>> >and replays them when prompted.
>>
>> .. of successful response messages..? or somesuch - not much point caching
>> error results.
>
>Sure there is. If the error is from the server, not a meta-error
>about not being able to reach it. I.e., if the content isn't there,
>why keep going back?
Because it might be there later? I don't know what the caching rules are
for error-information - is there a standard? Just because a page isn't
there now should not mean the cache keeps on just returning *that*
information - it should
(always/frequently/occassionally/when-prompted/whatever) check if the error
status has gone away.
At this stage I can really only see this as an issue on caching of
(semi-)dynamic pages, so perhaps that is a different kettle of worms anyway
:-)
>> Agreed. A 'server-side' cache is designed to take load off the origin
>> server, but does nothing for the network or performance as seen by the
>> end-user.
>
>I can affect the performance seen by the end user, if
>that performance is limited by the server bottleneck.
>If that server-side cache pushes, uses multicast, etc,
>it can also reduce network load.
Yeah, alright. Although a cache that pushes content doesn't seem like a
cache to me - but perhaps that's just my gut feeling. Populating caches
downwards in a hierarchy with e.g. multicast seems to be part of a
different scheme of things somehow...
>> A 'network' cache is designed to speed up responses for the
>> end-user and reduce network load.
>
>s/and/or - it can be either.
Of course. (And I didn't want to introduce another term, it was just in
contrast to 'server-side' :-) ).
>> No - it "intercepts" _all_ requests, but if it can't service them will
>> forward them on on behalf of the client, and store the response while also
>> passing it on.
>
>Define "intercept" - I was intending it to mean what you do with
>messages you don't forward. You mean something different. Maybe
>'responds to' is better than 'intercepts'?
Yes.. 'Intercept' in almost all uses I can think of has a connotation of
something unexpected, it changes the flow of events, e.g. in sports, where
something is going one way and is suddenly taken another way. However, if
caches were truly transparent to the end-user (i.e. they are like a
"feature of the network") then intercept is probably right. But I think
'responds to' is a good choice.
Imagine if one day we had true resource-discovery where you did a multicast
HTTP GET for some URI, then it would be the first 'box' of whatever type
that (positively) "responded to" your request that becomes your
data-provider. Yet no single box can "intercept" your request (in my use of
'intercept'). "Responding (to)" has a broader, safer, meaning perhaps...?
> While anything we can create
>can have any combination of these capabilities, the definitions
>focus on the 'pure' forms of each capability, no?
For sure. I totally support the brief summaries (client for server, server
for clients) and think that is all that is needed. I was just responding to
somebody else's comment about interception being added in. I don't think it
is needed in (that part of) the definition. Elsewhere maybe.
>> >> Replica Origin Server
>> >> New definition. Editors View - Open Disussion
>> >> Editors-Note: In light of the recent disuccsion, the authoritative
>> >> attribute is quiestionable.
>> >> "origin server storing a persistent replica of a data set
>> >> stored at the authoritative reference"
>>
>> How is this different to a mirror ?
>
>I think a mirror is about the entire server; a replica is about an object.
>I.e., 'servers (or databases, or data sets) are mirrored;
>'individual objects are replicated'.??
Is a database an individual object or a set of objects ? Is a shareware
site? I'd vote for mirror=replica, forget about the size or number of
objects (or fraction of server) involved. Lets reduce the size of the
dictionary :-)
Cheers,
Markus
Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810
email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST