> > > > Based on your comments, the project team has an updated spec.txt (v2)
> > > > at the material directory. Please see
> > > > http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2008/021/material/spec_v2.txt
> > > >
> >
> > I don't see the default values discussed in the updated
> > spec. IMO, these seem important to the user experience
> > and relevant to the case. When Solaris first installed,
> > what will occur if the Lid is closed, what is the LCD brightness,
> > what action does the power button have?
>
> I think you have your cases mixed up. This case doesn't define any
> defaults, but implements requests: i.e. "Can the user suspend, if yes,
> suspend, if not fail". What the "defaults" are (or maybe "install
> defaults") would be part of a tool (such as GNOME Power Manager
> LSARC/2007/702) that would use these interfaces. And even if the
> installed default for that tool indicates a suspend on lid close, if
> the user doesn't have the authorization to suspend, the machine won't.
I guess I still miss seeing the big picture I've asked for
(at least at LSARC). This seems to be playing he said she said.
So, just what useful will be delivered to the customer/user of
all this stuff?
> > Perhaps parochically, I also don't see why the policy, which I
> > believe is implemented in HAL, should not just depend on PSARC/2008/034
> > Defining Workstation Owner Infrastructure. And thus this
> > case have a dependency to that one. Afterall, this/that is
> > exactly why 2008/034 was submitted. It seems to me implementing
> > your own /dev/console and authorization tests side step the
> > architecuture of allowing the Administrator to have control.
>
> This case doesn't intend to implement /dev/console tests and will
> use chkauthattr() with the auths specified in this case to determine
> if a user has the appropriate authorizations. It is mostly a courtesy
> that it references any future "console" related tests or cases, and
> (IMHO) doesn't directly care about PSARC/2008/034 (though that case is
> probably more dependant on this one as it is trying to define the what
> the rights of a "Workstation Owner" are, and I suspect that the power
> profiles defined here should be included). If the code for
> PSARC/2008/034 exists, then the user will be able to get permissions
> just by logging into the console, if it doesn't then they will need to
> be explicitly entered.
So before I disagree, where is the customer/admin docs that
will be supplied to tell how to use this? Where is the administrative
interface? I guess we can just ship another erector set with
no instructions and missing parts and let the end user/admin
try to figure it all out. Sigh, IMO that is totally broken
from an ease of use and KISS perspective. So, I'd disagree
architecturally part of this case should be to deliver rights
profiles into the PSARC/2008/034 "Workstation Owner" Rights Profile.
Gary..
