Re: comments? mirrors.txt

When I suggested my mirrors.txt idea I had few things in mind:

- Descriptive information on the mirror, including the hoster's
name, a description of the mirror and any other meta-data
that might be fo interest. Although I would love to ignore the
present commercial environment of the internet, plenty of
services are provided in exchange for publicity. Take the possibility
of publicity away and for such entities you also remove the service
that they wish to provide in exchange.

- The possibility that the information could be used by a search
engine for smart redirection.

- Human readable fall back. The idea being that I can provide the
advanced functionality to smart browsers, yet at the same time
provide the information in a way that old or barebones browsers
would be able to deal with. Often this would be to show the bare
file to a human who would be able to make sense of the content.

Reading the thread and looking at some of the cases out there, there
appears to be two main groups of mirrors: transient and semi-persistent
(this includes persistent). Transient mirrors are like the nodes in
a peer to peer network and probably few care about where they are,
who is providing the information, etc. Yet a semi-persistent mirror
is a service unto itself and should be recognised as such. Maybe the
following analogy might work:

You walk into a service office, where turn over is high, you just want 
the service and don't care much about the identity of the person serving
you as you know they won't be there next time. On the other hand you
walk into another service office where almost every employee has been
there for more than four years. You get used to a certain quality of
service and you want to be able to recognise the person that is always
serving you and you use them all the time because you are happy with
what the service they provide.

If a solution can be defined that is flexible enough to handle both
scenarios, then I would like to see it. Ideally we should have something
that can provide as much or as little information as necessary. It 
should also be extensible with new types of information, as they
become necessary.

One thing I have against IP->loc databases, in this scenario, is that 
you are depending on a secondary service to provide information that 
could easily be provided from the current data set. The second issue is 
that have that information you are requiring a second service to be 
available. What do you do when the IP-loc DB goes down? This also
requires more communication. This is why I believe such information
should be part of the meta-data - see it as a pre-cached map ;)

Andre

Received on Thursday, 3 April 2003 11:51:30 UTC