There are several user-interface issues for Bolt that I do not feel
comfortable deciding for myself, at least not without some discussion.  Some
of these issues are standards issues that apply more broadly than just to
Bolt.  Some require deciding how the software is likely to be used (which
will, in the absence of a marketing department doing some kind of market
research, require us to take our best guess).  All of these issues will
have to be decided based on some tradeoffs between what is desireable, what is
possible and what is practical.  I anticipate more issues being added to those
listed below and some physical meetings on some of the issues, but let's hear
YOUR $.02...

net: icon - There is currently no net:disk.info.  How important is it to have
a net: icon which can be snapshoted and have alternative (from the default)
imagery?

node icons - should they be stored local to the server or client?  Should the
server store default icons but the handler override those defaults with local
icons if the user snapshots/iconeds those icons?  Should any defaults on the
server be stripped of snapshot information before being sent to the client?
What about window size/placement?  Currently they are stored only on the
server, are not modified by Bolt and are write-protected.  The effect is that
they cannot be snapshoted by a client, may be messy because they've been
snapshotted by the server and there is no way to coordinate window size/shape.

device icons - should non-filesystem devices be given icons at all?  All
device/volume icons are currently type drawer.  This works OK for filesystem
devices, but non-filesystem devices don't work with this very well (Sinz has
already suggested type 'project' icons).  It is nice to have the node window
provide the information of which devices are accessable as icons for every
accessable device.

XXX.info files - when accessing a remote file system via NET:, what, if
anything, should be done about snapshot information?  If not, how can you
prevent it without causing difficulties for programs that save icons?  If so,
should users be able to snapshot remote files?  Should doing so affect only
the user's view of those files or everyone's view?  What about servers using a
moniterm being accessed by clients with 1084s?

Copy files from one remote hd to another remote hd can't be done via wb (wb
tries to rename the files since they are (as far as wb can tell) on the same
device).  What should we do about this?

You cannot use 'info' on a subdirectory, so there is no way to get info for a
remote device.  How important is an 'info' utility for Bolt?  'Info' on net:
currently returns a size of 0k with 1 block used and 1 block free per mounted
network node.  Is this reasonable?  Is there something better to reply with?

location of files - currently configuration info is stored in devs:networks and
it's subdirectories, the driver is placed into libs: and the handler and
server are in inet:c/.  These don't seem like the right places.  Should I keep
configuation info in ENV:/ENVARC: and write a preferences editor (to go in
Sys:Prefs) for Bolt?  Should I continue to require my driver library to go
into libs:?  L: makes a little sense for the handler and server, or should
only 'mount'able things go there?  Should a sys:xxx directory be created for
all network servers or should my handler and server go where the network
protocol/utilities software goes (whereever that may be)?

security - this is a UI issue in that it must, by definition, get in the
users' way, and we must decide how to best minimize that effect on legitimate
users (as well as server administrators).  Currently, a default access list
determines which devices or directories to export.  The plan is to add
password protection to the default list and to allow additional lists
protected with different passwords.  If you wanted to access a server with a
protected default access list or with an alternate access list, you can use a
password activation program to send a password and the access list you want to
use to the remove server.  We will probably also allow you to specify a
password/access list in your handler startup so that after you've put a
password on your machine you'd never notice it.  This is a problem with
client machines which aren't physically secure accessing servers which are.
This would amount to protection by group rather than by user (though you
could, in theory, set up an access list and password for each user, you
wouldn't want to).  Should we have a user-oriented protection scheme?  Is
using the password program each server each time you boot before you access a
server unreasonable for a 'secure' environment?  Do we need a mechanism for
enforcing disk quotas (a disk quota is allowing users only X amount of HD
space)?  For finding out who created file XXX?  If we do, we need a notion of
file ownership.

