Re: root knowledge

[Thomas Johannsen <[e-mail]>]

> From: Andrew Waugh <[e-mail]>

> distribute this subtree across DSAs run by the Australian libraries? The
> problem is, of course, that we are attempting to store data in X.500 which is
> not distributed organisationally.
> 
> 'Archie' addresses a similar problem. Files are held in geographically
> distributed file servers, but, logically, the files are not organised in
> a geographical way. Archie 'solves' this by periodically polling each
> archive site and using the information retrieved to build a list of
> files and sites which hold the file. This is actually more useful for users
> as they merely have to query Archie instead of explicitly searching individual
> file servers.
> 
> Locally, I have recently suggested using X.500 as a means of providing
> better access to the Archie data. Currently the problem with finding a
> particular software system is that you need to know the name of the file to
> ftp. It would be simple to construct an X.500 system which stores information
> about the software systems available for anonymous ftp. Users could easily
> search this system for 'freely available osi implementations' (:-) using
> already available DUAs. Because of the non-geographical nature
> of the data, however, this solution would still rely on an Archie style
> polling of ftp servers to actually build the X.500 database.

You mentioned two different problems and I think we should distingish them.

1) how to get information where a file is hold:

 Archie certainly is useful. However, it has several disadvantages which
 might be overcome by using X.500. 
 a) There are several central archie servers, each of them holding
    information for a certain set of fileservers. An archie enquiry is
    restricted to this (more or less well chosen) set of ftp sites. It
    looks like the Directory with isolated countries trees (no
    interconnection via root level). 

 b) If two archie servers provide info for the same ftp server, they *both*
    have to poll this site in order to update their info.

 On the other hand, representing file server contents in the Directory will
 give information about "every file stored anywhere" (might this be useful
 or not). The updating of this info is a one step procedure: The ftp site
 just has to update "its" Directory entry and you are done. No polling from
 a lot of info (archie) servers to this site.

 Coming back to this "geographical" aspects: Of course ftp access should be
 made from the nearest ftp site holding the file you want. Archie can not
 tell you which ftp server is "near" or "far". It can only limit it's list
 of supported file servers, but this results in limitation of the info
 provided. Of course you could guess from the sites domain name where it
 is. Putting ftp site info in the Directory with a relationship to the
 organization maintaining it tells you more about the locality. You can
 restrict your file search to "your Directory subtree" or to your country.
 Furthermore, we (i.e. the Soft Pages Project) are going to put network 
 configuration information into the Directory in order to tell which 
 network connections should be preferred (with respect to network load,
 charge, etc.), i.e. which ftp server to contact if there is a choice.
 
 If you are interested in more details, have a look at
 ftp.tohoku.ac.jp:pub/spp/odr.ps.

2) to know more about a file:

 Sure, the Directory offers a lot of opportunities to hold more info about
 a document (like keywords, author...). Although there is no real standard
 so far, I'll see no problem of connecting ftp site contents (i.e. file
 name info) with this file contents info, later.


> 
> andrew waugh
> 

Thomas