Push vs Pull - Did the origin server (treating such as well defined for
now), decided to put the information in the "sometype" replica, or did
the "sometype" replica decide to get / keep the information?
Both exist from the same servers! As a mirror operator, I know that we
both get asked to actively be a mirror by content owners, and have to
ask if we can replicate. And I know that for some sites we mirror we
asked, and other mirrors *of the same prime site* are in some sense
more 'official' which is extremely galling.
Expiration - Is the "sometype" replica responsible for expiring the
information based on its own clock, or will the information provider
notify it when the information should be considered invalid.
(Obviously, there are combinations.)
There is an added twist here that some origins 'police' their mirrors
and others do not. I'd say there is a dimension of Service-Level-Agreement
here in terms of what is considered 'acceptable' staleness of mirrors
which varies on a case-by-case basis. Maybe we can be setting the agenda
for what is a user centric view? or a taxonomic input into the parameters
of how mirrors and content owners negotiate about this?
Full versus partial copying - This ne is slightly different in that I
doubt that one would ever build the system around "copy the entire
server". Even "full copying" would just be some subtrees. And one
could easily imagine cases where not even the entire tree from a given
point down was copied.
There is another semi-legalism here: Some origins *DEMAND* you take the
whole tree (well sub-tree) of some content. Notably, commercial ones
who insist you take advertizing.
Scripts - There is a tendency to assume that script execution goes with
Push and originating execution. While that is the current state of
practical affairs, binding that into the terminology and taxonomy of the
system would seem to be a mistake. One can imaging, as the technology
gets more sophisticated, that partial databases and scripts could get
replicated in a demand fashion with distributed refresh and other
properties.
Don't think its that clear. Scripts often don't go over well in mirroring
and while an initial execution runs on the mirror, subsequent calls go back
to the parent because of hard-coded URLs.
PS: I think that actually many members of this group have a similar view
to what I am trying to say above, but I could not detect it in the
recent conversations.
I think on the coupling issue, you are right. I'm not sure (coming from
a mirror managers perspective) I agree.
This drifts a bit from a taxonomy issue, but I think it helps to remember
that caches, proxies and mirrors are about two things: QoS and Money.
The QoS dimension matters most to users in the main. Apart from a branding
issue (faster downloads from us!) there isn't much in that for a provider
of service. But money talks. Mirrors can have a 10:1 or better leverage
over the offshore data-fetch in re-use and that is a very large financial
incentive to direct traffic internally.
But that also means many of the issues you raise above come into play since
they are about control of the process. I think the issues that come up
reflect the knowledge and motiviations of both sides of the fence!
cheers
-George
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:26 MST