Issue 1: User Interface Design
Status:  Done
Owner:
Closed:  Aug 2009
Cc:
Project Member Reported by brantgu...@gmail.com, Jun 29, 2009
After the bit of feedback I've received and reading through the MMC 3.0 
Design Guidelines, there are some issues to address:

Who are the target users of the console? This can impact the scope nodes 
offered so that consoles can be created showing only the relevant nodes 
for that user type.

According to the MMC Design Guidelines, it looks like it is desirable that 
everything that is done through the user interface be able to be put into 
a script form, generally Windows Powershell it seems. Do we want to do 
this? It seems desirable in the long term, but I think it might involve 
more than I can do in the time of Google Summer of Code project. It also 
involves learning how Powershell works.

According to both feedback from Chris Clausen and what I read in the MMC 
Design Guidelines, it seems desirable for many of the tabs from the 
prototype to actually be scope nodes under a top level node where the 
service can be started and stopped and perhaps a log summary can be seen.

I've also been informed that some things like the CellServDB can now exist 
in the registry, so do we want one to be the 'authority' and offer 
converting from one to the other in the CellServDB portion of the settings?


Jun 29, 2009
Project Member #1 brantgu...@gmail.com
(No comment was entered for this change.)
Cc: jaltman
Jun 29, 2009
Project Member #2 jaltman@gmail.com
The target audience of this console are system administrators for the local machine.
 It is not intended to be used by day-to-day users.  A casual user might have to
adjust the settings once after installation but beyond that they should not have to
think about them.

The question of logs is an interesting one.  We could have a read only edit control
that displays the contents of the various logs (afsd_init.log, afsd.log,
afsd_alloc.log, ...) if they exist or summarize the contents of the Windows
Application Event Log.

This MMC will not have a variety of user types.  The plan is to build three different
interfaces:

  1. a new control panel which provides users with the ability to 
     manage their credential acquisition (aka NetIdMgr AFS provider)
     and their PTS group memberships for arbitrary cells.  This is 
     expected to be used by casual users and should not require 
     privileges.

  2. the cache manager MMC (this project) which requires membership
     in the OpenAFS Admin Group to make changes although anyone can
     view the contents.  This is intended to be a system administrator
     tool.

  3. the openafs cell MMC (the former Capstone project) that is 
     meant to be used primarily by cell administrators and power 
     users that are interested in exploring cell configuration.
     This tool makes no changes to the local system.

There should be no need to scope nodes to different user types.  The only difference
is whether they should be permitted to make changes or not.  

All of the registry configuration options for the cache manager are documented in the
Release Notes .chm in Appendix A.   Have you perused it?   Only the HKLM options matter.

As for changing the contents via PowerShell, my understanding is that anything C#
class can be driven by PowerShell.  However, this is not a priority at the current time.

Aug 22, 2009
Project Member #3 brantgu...@gmail.com
I think the UI design is rather set at this point for this version until it is 
functionally complete anyway.
Status: Done