Subject: terminology suggestion

From: Micah Beck <[email-masked]>
Date: Fri, 20 Aug 1999 19:07:19 -0400

Wojtek Sylwestrza

> When I hear service replication, I picture manually configuring remote
> servers
> (FTP, Web or other) and then mirroring the data from the origin server
> onto them.
> 
> The  first part of this process is more or less manual, and one-time
> only.
> The second task is automated and periodical/continuous.
> 
> Performing these both steps allow us to provide service on the replica,
> but i'm not sure if it's necessary to have a special terminology for
> this.
> 
> Do I understand service replication right, or does it have a broader
> sense ?

I intend "service replication" to mean any situation where a service is 
available in more than one place.  Manually set up mirroring is one example,

Joe Touch wrote:

> Prefetching or push caches can grab the copies of an 
> entire server (assuming it's completely 'connected' via internal
> links) a-priori. Isn't that all prior to the request?

If it's in response to a request then I'd say it's on-demand (like
fetching a line of a memory cache).  I can see the argument for calling it
a-priori, but my point is that it is a part of a response to a request, and
would never be fetched if the request were not made.  Admittedly, copying
policy is very complex, and I am attempting to simplify by naming just
one dimension.

> I see the difference as a combination of all three factors
> 	- ahead of time
> 	- entire database
> 	- permanent copy (source invalidated, vs. timeout in a cache)

Here are some suggestions for terminology:

1. never use the word "replication" with out a modifier: service replication,
source replication, output replication

2. mirroring means source replication

3. caching means output replication

4. We chose another word, perhaps "dynamic Web caching" to mean output copying
with an on-demand copying policy, which is common practice.

5. We chose another word, perhaps "static Web mirroring" to mean a-priori
source replication, which is common practice.

6. chose other modifiers for "entire channel" and "permanent copy" as Joe
suggests.  As he points out, there are many possible variants to the 
policy of what get copied when, but I think this covers the major ones.

/micah

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Sun, 22 Aug 1999 12:03:52 +0200

> available in more than one place.  Manually set up mirroring is one example,

Sorry, I was not clear. 
What I meant was that the whole process of "service
replication" as I understood it, consists of two parts:

1. configuring the server on replica to provide the copied contents.
   whether this is an FTP, HTTP or some more complex database server,
   I cannot imagine doing this other way than manually

2. configuring the mirroring process (a mirror scripts, rsync or such)
   to update the contents of the replica periodically or continuously
   (this obviously is a manual task, but that's not the point)
   and then running it automatically.

So again, my understanding was, that task 2 is called 'mirroring'
while if we want to name both 1+2 together, 
this would be 'service replication'.
And 'service replication' does not necessarily have to involve
mirroring,
the particular technique used in step 2. can be caching or something
else.

I think this also fits with your definition.

--w

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Sun, 22 Aug 1999 12:14:44 +0200

Micah Beck wrote:
[...]
> 3. caching means output replication

this is a little controversial when the protocol used to provide
the service on a replica is the same as the one used to perform
the actual copying.

Examples:

if the service is http, and it's being mirrored using wget,
we are copying the output of the origin server. does it mean
we are caching it ? no.

in classical ftp mirroring, both the service protocol
and mirroring protocol are ftp. in fact what we are doing,
is we are mirroring the output of the origin ftp server,
not its source, as there are many ftp daemons that
are configured to hide parts of the source tree 
(or individual files) from anonymous users.
this again can hardly be called caching.

my argument here is that the distinction between
source replication and output replication as
a criteria to differentiate caching from mirroring is 
a wrong one. we are always replicating the server's 
output. unless we are copying raw filesystems,
or at least the complete tar files of the source.

--w

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 23 Aug 1999 07:55:47 +0200

> the service on a replica is the same as the one used to perform

Not really.

The difference then is what you copy, and how.

Mirroring: Sheduled copy of the data output.

Caching: On-demand copying of the protocol output.

In HTTP this translates to that a mirror only copies the data content,
while a cache also mirrors part or all of the protocol headers
(content-type,...) on a per object basis.

A cache also typically copies information on demand, while a mirror is a
sheduled (or syncronised) update of information.

--
Henrik Nordstrom

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Mon, 23 Aug 1999 08:35:21 +0200

> (content-type,...) on a per object basis.

Indeed - this makes the difference.
The 'protocol output' appeals to me more than 'server output'.

--w