KfM 4.0b7: a few questions

[Gavin Eadie]

At 11:27 AM -0500 1/31/02, Ken Hornstein wrote:
>I'm not saying this is desirable; I'm just saying that this is what
>I think the guys at umich wanted.

... first, let me be clear that I only opened this for a conversation 
on the merits of a point of view and was NOT asking for anyone to 
change anything in KfM 4.0.  In retrospect, I realize I may have 
polluted the list and/or caused the MIT guys to take valuable time 
out from getting KfM 4.0 done to engage in mere chit-chat.  IF there 
were any prevailing sentiment to make such a change, or provide it as 
an institutional option, it'd be for a KfM 5.0 (4.1?) feature list.


>Well, this didn't seem that hypothetical; the guys at umich (please speak
>up if I've got it wrong) seemed to have not a "policy", but a preference.
>And as I understood it, they didn't want to get rid of dialogs completely,
>just ones that weren't explicitly triggered by the user.

... well, even here at umich there may not be agreement!

     By the way, the "application" I was thinking would be used to 
refresh/obtain tickets would just be "Kerberos" -- the app/control 
panel that MIT currently launches automatically.  I certainly don't 
want any other app to get involved.

     At the risk of extending the conversation, let me surmise that, 
when Mac OS X login can use Kerberos and obtain a TGT, this issue 
will largely evaporate.  With the software available today, the first 
Kerberized application that runs (Eudora, Mulberry, Fetch, ...) 
causes the 'get tickets' dialog to be presented in order to get 
tickets ... in the future, we presume, the process of logging in will 
satisfy this need and that such applications will no longer require 
this intervention (for at least as long as a ticket lifetime).