From:	MERC::"uunet!lrw.com!lrw!leichter"  1-JUN-1992 15:20:15.28
To:	EVERHART
CC:	
Subj:	Ideas for BOSS

I picked up V4.2 when it was posted to vmsnet.sources a week or so ago.  After
corresponding with Charles, I picked up a copy of 4.2a from a machine at
Princeton.  It has some fixes to memory allocation from Kenn Humborg.

BTW, apparently there's an even more recent version of FILE than the one you
sent me - a note about it just appeared on INFO-VAX.  Ned Freed fixed some
unspecified bug having to do with local negated qualifiers, or something
like that.

The kind of things I'm thinking about for BOSS include the following:

1)  It would be nice to be able to specify a string to be sent to a process
when you switch to it.  The most likely string, of course, would be a single
character, either CTRL/W and CTRL/L, to cause a repaint.  Some of the things
I'd like to keep around all the time are NEWS and full-screen editors; with
this addition, switching to them would just "work" right.

Actually, I can't think of any good reason to send more than one character,
but you never know.  Then again, if it's one character you can have a
simpler-to-type syntax.

[Charles pointed out that the /STUFF_STRING value would be stuffed whenever
you switched processes using the BOSS$SWITCH logical.  This is NOT what I
expected from the documentation, but it also doesn't really solve the
problem.]

2)  The current screen repaint is forced into a compromise:  You want to
store a big buffer of information so that you can restore in as many cases
as possible, but you don't really want to wait while tons of characters are
sent to the screen.  Suggestion:  De-couple the size of the buffer from the
default size of the refresh.  For example, you might buffer 16K of data but
only replay 1K.  An explicit user command would replay a bigger piece.

[An interesting problem raised by both 1 & 2 is the lack of a good way to
specify DIFFERENT settings for control parameters in BOSS.  The only way
you can do it at present is during startup, when some qualifier lists, like
/STUFF_STRING, line up with /START_PROCESS.  What BOSS needs, I think, is a
command mode - the two-key sequences are great for the common things, but
for complex things they get out of hand.]

3)  It would be VERY nice if you could, in a keystroke or two, be placed in
a callable editor with the contents of the current session's buffer available
to you for editting.  There would some convention for passing stuff back from
the editor to be "stuffed" by BOSS.  A very simple approach:  The editor is
started writing to some file.  The buffer contains all the data, then a
recognizable "end of input" marker.  On exit, BOSS reads the file, searching
from the "end of input" marker, and stuffs everything after it.

I've got a hack like this (modified from code pulled off the net) that works
on the DCL recall buffer.  Very handy at times.

4)  I like the ability to communicate information among subprocesses through
the job table.  There's a simple way to extend this to detached processes,
at least if they are logged in under the same UIC (or are privileged,
actually).  Any of your processes can place logicals into the job tables of
any of your other processes.  The only difficulty is FINDING the job table
of another process.  However, a process can easily find ITS OWN job table's
real name by translating LNM$JOB in LNM$PROCESS_DIRECTORY.  So, all that's
needed is a convention for passing the name back or forth between BOSS and
a created detached process:  Either the process tells BOSS its own job table
name (in which case BOSS looks there, and you can define things in the job
table whatever the process type), or BOSS tells the process its name (in which
case BOSS looks where it's always looked, but you have to know where to place
the communication logicals.  What I'd do for this case is always define a
BOSS_TABLE logical which you could use in any process.)

BTW, I'm a little surprised about the use of logicals here.  Is it really
cheaper to check for a logical than to scan the output characters?  The OSC
sequence is a natural for sending data back from the controlled process to
BOSS.  In general, however, you're much less likely to have trouble finding
a character that will "never" be sent TO a terminal than a character that
will never come FROM a terminal.

[I'm rather over-loaded right now and unlikely to work at these, with the
possible exception of 1, which seems pretty simple - especially since you
can generally send CTRL/W safely to ANYTHING; it either repaints the screen
or is ignored by all VMS-style programs.  Yes, I know, EMACS has its own set
of rules.]

							-- Jerry