| Issue 1: | User Interface Design |
1 of 26
Next ›
|
| 1 person starred this issue and may be notified of changes. | Back to list |
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
Cc:
jaltman
Jun 29, 2009
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
I think the UI design is rather set at this point for this version until it is functionally complete anyway.
Status:
Done
|