|
|
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 accessfails. I assume TRUE for now.
WN31.DOC still contains a reference to the WNetViewQueueDialog API. Isthis 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 thecompat-mode properties field? It makes my life slightly easier toseperate them with spaces (as does the API).
While we're at it, why is this read-only? It seems to me that the usermay 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 movethe share to another server. This was one of the reasons we wanted to provide the capability to change servers in the first place. Anothergood reason to nuke this functionality!
Lines 483-484: I don't think we should create a new DosPrintQueue unlessit is necessary, possibly if we change the list of ports, certainly if wechange the server. Remember that DS propagation delay will make thenew queue unreachable for a while. There are also more failure modes oncreating a new queue and deleting the old one.
Lines 457-458: Do we use the same model for all drivers? If not, wemust prompt for model every time we add a new driver.
Lines 421-422: Is it necessary to create a new port when only theprinter list is changed? Is this error message appropriate in thiscase?
Lines 529-530: Do we want to force the admin to delete+recreate theshare just to change the password?
=====LOGON=====
Why do we compare the old and new passwords case-sensitive? There is nosuch thing as a user password on a core server.
=====OTHER=====
Do applications other the the Print Manager Extensions need to be notifiedof changes in logon status? One scheme proposed is to broadcast auser-defined message selected by RegisterWindowsMessage, which anyinterested 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 easiestto implement if the error message were not specific to the preference beingwritten, although it may contain a field on the type of error. The userprobably knows what preference was being changed anyway.
|
