Issues wrt Specs
-----------------

	preamble - pls list your issues below. Be sure to explain
	problems & suggest alternatives. 

							chuck, 4/28/91

	JonN  5/1/91   Added some items relating to Test Driver code review.
	JohnL 5/3/91   Added own take on field updates, magic group behaviour
	JohnL 5/14/91  Added Message popup on top of Set focus dialog

------------------------------------------------------------------------------


=========
STANDARDS
=========

Saving App coordinates & sizes in DS. Problems include:
	a) extra access DS slows things down.
	b) need extend schema, another thing to install correctly
	c) different display monitors make things messy, yet more
	   code needed to do the right thing. Ditto if errors when
	   accessing DS.
	d) if bring app up, shutdown & bring up again, good chance we
	   dont get same result unless we hit master always, which is
	   not acceptable.
    Suggest we store the stuff locally. Wont follow user about, but then
    none of the other apps (like WinFile, PrintMan) do anyway! None of the
    above will be an issue.

Saving parameters
    Are parameters like fConfirmation shared between PrintMan,
    UserTool, etc.?  Should we have an internal WINNET API to handle
    this?
    We need a master list of every configuration parameter, eventually
    we will have to define an LM_GUI_CONFIG DS class.

Saving attributes one at a time. We can do this at moderate coding cost 
with ParmNums, but a few other issues arise:
	a) if user has multiple select & sets several items, the number
	   of times we hit the net can be pretty high. 
	b) if we set all at once, and get an error, the object is 
	   unchanged. If we set one at a time, and get an error halfway,
	   the object is half changed. This makes it much harder to explain
	   to the user. Backing out is not a solution either. We have hit
	   an error and there is good change we cannot backout.
	c) DS efficiency issues? 
    The problem we are trying to solve is what happens if 2 admins modify the
    same object. The proposed solution of only setting the attributes that have
    been modified partially solves the problem, but introduces some other
    problems that need to be looked at carefully. Suggest further investigation.

    John's addition to the above: So we are going to force the majority of
    the admins to suffer from slower data entry/editting for a situation
    that *might* happen once in a blue moon?  There *are* worst case scenarios,
    but if we are really concerned about the user losing data, then we should
    do some type of record locking mechanism (is this possible?) which prevents
    multiple admins from editting the same record.  The proprosed scheme
    doesn't really give the user anything except a slower program
    and a *lower* chance of losing data.

Timer Refresh in main window issues
    With automatic refresh, we run the risk of calling for refresh more
    frequently than we can perform them.  Do we have some uniform way of
    detecting and handling this?  [both FuncSpec and CDD issue]

    The behavior specced on lines 198-200 is not consistent with lines
    444-446.  The behavior specced on lines 198-200 is difficult to
    implement, since a window does not typically know whether it is in
    the foreground of an application.  444-446 is much easier to
    implement, and seems to me to be good enough.  If this is necessary,
    would it be acceptable if this applies only to dialogs we display
    (i.e. not to dialogs displayed by the Print Manager proper)?

Logon Dialog position
    I had previously understood that the Logon Dialog was centered only
    when called during Windows startup.  Should it always be centered as
    per line 60?

MsgPopup on top of SetFocus dialog
    The current spec. states that when an admin app encounters one of the
    following:

	1) an invalid domain/server on the command line
	2) The user running the application doesn't have the
	   necessary authority on the specified server or
	3) An error occurs when getting initial data from the domain or
	   server given

    (these are all during start up) the Setfocus dialog appears, then, on
    *top* of the setfocus dialog, a message popup appears stating the
    given error has occurred with the prompt: Do you want to select another
    domain or server to administer?  If the user selects "No", then
    everything goes away, else the user is placed on the setfocus dialog.

    I propose changing the behavior to the following:

	Error occurs
	Show Message popup with same contents as above, if the user presses
	    "No" then everything goes away, else the Set focus dialog
	    is brought up.

    This is primarily a development issue.  The implementation is easier
    of we can just put up an error message then the setfocus dialog.  The
    current behavior doesn't add anything for the user (in fact, the
    MsgPopup will probably cover the Setfocus dialog).


=============
PRINT MANAGER
=============

Move queue from one server to another. This is very hard to get right:
	a) we need to worry not just about the Queue, but all its 
	   associated stuff: printers, drivers, ports, permissions, 
	   auditing, etc.  Not all of this info is remotely available, so 
	   it is very easy to go wrong. 
	b) How often will users do this? Unlike DFS volumes, people do not
	   move printers from one server to another frequently, since there 
	   is a physical element of the print hardware involved.
    Suggest we nuke this. To properly setup a printer, the user needs to
    setup from Print Man anyway, so just have the user to delete and recreate.

When the user pauses a printing print job, it is the print _destination_
which should be paused, rather than the print queue (thx Chuck).

Please spec default setting of "Admin Menus" preference if DS access
fails.  I assume TRUE for now.

WN31.DOC still contains a reference to the WNetViewQueueDialog API.  Is
this obsolete?

If a job was submitted locally (from an OS/2 app running on the server),
the job's username is NULL.  Should we pass some string, perhaps
"LOCAL"?

Is it important to seperate the devicenames with commas in the
compat-mode properties field?  It makes my life slightly easier to
seperate them with spaces (as does the API).

While we're at it, why is this read-only?  It seems to me that the user
may well want to change the list of ports in the compat-mode dialogs,
and it isn't difficult to support.

Lines 387-391: This implies that if the server is down, we cannot move
the share to another server.  This was one of the reasons we wanted to 
provide the capability to change servers in the first place.  Another
good reason to nuke this functionality!

Lines 483-484:  I don't think we should create a new DosPrintQueue unless
it is necessary, possibly if we change the list of ports, certainly if we
change the server.  Remember that DS propagation delay will make the
new queue unreachable for a while.  There are also more failure modes on
creating a new queue and deleting the old one.

Lines 457-458:  Do we use the same model for all drivers?  If not, we
must prompt for model every time we add a new driver.

Lines 421-422:  Is it necessary to create a new port when only the
printer list is changed?  Is this error message appropriate in this
case?

Lines 529-530:  Do we want to force the admin to delete+recreate the
share just to change the password?


=====
LOGON
=====

Why do we compare the old and new passwords case-sensitive?  There is no
such thing as a user password on a core server.


=====
OTHER
=====

Do applications other the the Print Manager Extensions need to be notified
of changes in logon status?  One scheme proposed is to broadcast a
user-defined message selected by RegisterWindowsMessage, which any
interested app can watch.

Please spec an error message for failure to write user preferences to the DS,
e.g. failure to write the Confirmation preference.  It would be easiest
to implement if the error message were not specific to the preference being
written, although it may contain a field on the type of error.  The user
probably knows what preference was being changed anyway.
