MIRRORING

Murray-Rust Dr P (pmr1716@ggr.co.uk)
Thu, 26 Jan 1995 12:38:54 +0000 (GMT)

On Wed, 25 Jan 1995 Dierk.Seeburg@asu.edu wrote:

> Dear Dr. Murray-Rust,

[nice things about course deleted :-)]

> One of the concerns I have is in regard to the server access. We have
> already discovered that the closer we are getting to the actual start of
> the class network traffic is quite heavy. I was disconnected a few times
> and/or my connection was refused by the host computer. Thus, I would just
> like to ask that precautions are taken that technical difficulties will not
> stand in the way of doing virtual science and education.
> Thank you so much for your time and efforts,
> Cheerio,
> Dierk
>
> Dierk Seeburg ,__o
> Dept. of Botany _-\ <,
> Arizona State University (*)/'(*)
> Tempe, AZ 85287-1601
> Replies to: agdxs@asuvm.inre.asu.edu
>
>
This is VERY important, Dierk.

I fully agree we have to have mirrors for the course and that we
keep them as up to date as possible. There are some interesting
technical and human problems. I'm copying in GNA-TECH which is the
technical group of the GNA. (I haven't talked much about GNA in this
course so far, but it is very important and when I have time, I'll
explain it :-) I'm also copying in Alan Bleasby at Daresbury where the
course first started.

MIRRORING THE CORE

It is relatively straightforward to mirror a single hypertree and
Alan Bleasby has agreed to do this at Daresbury and Sandro Magri in Italy
has also offered. MORE OFFERS WOULD BE WELCOME. Alan, correct me if I'm
wrong, but basically BBK will produce a script which forms a tar.Z of the
whole hypertree. Then the sites agree on permissions (e.g. which site has
access to what) and then a cron job does copies it every midnight and
unpacks.
IFF authors have used relative addresses there should be no
portability problems.

MIRRORING IMAGEMAPS

This shouldn't be a major problem, although I have found with some
servers that they need absolute addresses in imagemap.conf and *.map.
However, the script has to copy imagemap.conf and *.map files as well and
the mirrorsite has to know where to mount them - addresses may/will need
editing. CAN SOMEONE GIVE ME A DEFINITIVE ANSWER HERE, PLEASE?

MIRRORING CGI FORMS

This is much harder, because some forms create information (e.g.
annotations to documents.) Others simply carry out searches or whatever
and create documents on the fly. We CANNOT HAVE INFORMATION CREATED AT
MORE THAN ONE SITE UNLESS WE HAVE A DISTRIBUTED MECHANISM FOR MAINTAINING IT.
This will be a problem for all GNA courses and I'll throw this to
gna-tech!

MIRRORING OTHER HYPERTREES

This is really hairy! Many course members have made URLs available to
us. Some, like PDB, existed already, some have been specially created for
the course. At present vsns-pps simply points to these from its core.
We cannot automatically copy them into our core because:
- we don't hold the copyright
- we could not easily run a worm through the remote material and know
where the boundaries are (they might reference other servers which were
logically part of their 'group', but the worm wouldn't know).

My proposal (which I'd been planning to float - and this is a
good time) is:
IF YOU ARE A CONTRIBUTOR, PLEASE CONSIDER WHETHER IT IS
APPROPRIATE TO LET US MIRROR YOUR MATERIAL. IF SO, PLEASE ORGANISE IT AS
A READONLY-HYPERTREE (we can't cope with mirroring other CGI scripts!!)
and create a script to make a tar.Z in your top directory.

We would then copy this at regular intervals and bolt it into the
tree at BBK. The author would be fully recognised and the material would
carry their name, their institution's logo, etc and whatever copyright was
suitable. It would NOT be further available to BBK or GNA or anyone else
unless the author so specified. It would then be useful for there to be
two links in the hypertree - one to the living version and one to the
static version at BBK.

NOTE: JUMPING INTO THE MIDDLE OF HYPERTREES SHOULD BE AVOIDED IF
AT ALL POSSIBLE.

MIRRORING BBK MATERIAL

A number of links point to BBK material not specifically
connected with the course (e.g. 'recent structures') These would be
treated as in the section above. BBK authors may or may not wish to
participate.

MIRRORING THE HYPERGLOSSARY

The hyperglossary is going to have tremendous applicability and
will have an independent existence outside the course. It HAS to have a
central curation and therefore any mirroring will have to be done through
the hyperglossary project. It is still very new - I'm not sure, for
example, what role GNA may have in this. At the moment it MUST have a
central site for the entry of information, although read-only copies
could be mirrored. (It's rather like the GNA-personnel database, I suspect).

CLEVER IDEAS WOULD BE WELCOMED HERE!

CONCLUSION

This is an extremely challenging area and I'd welcome offers from
course members, gna-tech, or anyonbe else who reads this. (The previous
GNA course - C++ - created a great deal of valuable resource for
communication and management and this will also be a recurrent theme here!

P.

------------------------------------------------------------------------------
Peter Murray-Rust | "Nothing exists except atoms and empty
pmr1716@ggr.co.uk | space; all else is opinion" (Democritos).
Protein Structure Group, Glaxo Group Research, Greenford, MIDDX, UB6 0HE, UK
------------------------------------------------------------------------------