head	1.2;
access;
symbols;
locks; strict;
comment	@# @;


1.2
date	98.10.09.21.25.11;	author milind;	state dead;
branches;
next	1.1;

1.1
date	95.11.27.16.40.35;	author jyelon;	state Exp;
branches;
next	;


desc
@@


1.2
log
@Removed outdated documentation.
@
text
@
Actually, propagating pathnames is a very subtle problem.  For example,
suppose I issue the commands

                cd $HOME
                charmhost bar

Now, charmhost has to tell the nodes which "bar" program to run.  It
could do this in many possible ways:

The obvious thing for charmhost to do is to determine the current
directory and concatenate the string "/bar".  In my example, this
procedure generates the string

                /tmp_mnt/home/kale/jyelon/bar

This "absolute path method" has a problem: in my case, my home
directory is /home/kale/jyelon on the NFS server, but
/tmp_mnt/home/kale/jyelon on all the clients, so the file has
different absolute paths on the different machines.

So I invented method number two, the "server-relative path method".
I first figure out the absolute path of the file, and then figure out
which fileserver is exporting the file, and where the file resides
on the server.  In my case, this procedure generates the string

                dagger.cs.uiuc.edu:/home/kale/jyelon/bar

The nodes then convert it back.  Unfortunately, this method has a
problem too: it requires that the machines share an NFS file system.
It fails entirely when the machines have separate filesystems.

So I invented method number three, the "home-relative path method",
which you have seen in operation.  It checks whether the file is
under your home directory, and if so, makes it "home-relative".  In
my example, this procedure generates the string

                $HOME/bar

Naturally, this method doesn't work right either all the accounts you
are using have to have similar directory structures (even if the
machines share filesystems exactly!).

Another possibility would be to use a "search method", which basically
involves trying first the home-relative, then the server-relative
methods in succession.  I'm hesitant, though, since it sounds like it
would involve a lot of coding, would be slow (it would have to try one
method, fail, and then try another), and might produce unpredictable
results.

Another possibility would be to specify which of the above methods to
use in the nodes file, or in a command-line option.

Another possibility would be to use a "charm directory": require that
the nodes file specify a charm directory on each node.  Pathnames are
relative to the charm directory.  I dislike this method simply because
you shouldn't be forced to organize your projects according to what
programming language they are in --- you should be able to organize
them in any way you want.

My current favorite idea is this: eliminate the nodesfile, and most of
the command-line options.  Then, for each program, write a "control
script" (kinda like a batch-job script).  It would tell charmhost
exactly what to do --- which executables to run, which nodes to use,
which account, what current directory to use, whether to use rexec or
rsh, and so on.  Whenever you install a charm program, you would
create a control script for it.  charmhost could even run the control
script through cpp, thereby enabling you to do some quite
sophisticated things: for example, you could conceivably #include a
list of hosts, or you could use #defines to make it easy to modify the
"constants" in the script (eg, the program name, memory size, etc.)  I
like this idea, since it gives you very specific control over
everything, and is very customizeable.  However, it will be a while
before I can implement anything like that.

@


1.1
log
@Initial revision
@
text
@@

