home *** CD-ROM | disk | FTP | other *** search
/ GRIPS 2: Government Rast…rocessing Software & Data / GRIPS_2.cdr / dos / ncsa_tel / digests / v1.07 < prev    next >
Encoding:
Text File  |  1990-12-29  |  3.6 KB  |  104 lines
  1. NCSA Telnet Digest    Wednesday, 4 Nov 1987        Volume 1 : Issue 7
  2.  
  3. Today's Topics:
  4.               Blinking session
  5.               Blinking Session
  6.                 How to handle nameserving of nicknames
  7.                   Keyboard remapping and Multi-Finder
  8.  
  9. ----------------------------------------------------------------------------
  10.  
  11. From: John Matzka <johnm@jacobs.cs.orst.edu>
  12. Date: Fri, 30 Oct 87 12:53:32 pst
  13. Subject: Blinking session
  14.  
  15. The blinking session doesn't annoy me much but as was pointed out, it isn't
  16. really necessary since the menu bar will flash when sound is turned off.
  17. Perhaps this "feature" could be made an option perhaps this option could be
  18. set in the config.tel file.
  19.  
  20. John Matzka
  21. johnm@jacobs.cs.orst.edu
  22.  
  23.  
  24. ------------------------------------------------
  25. From: gaige@ncsa.uiuc.edu (Gaige Paulsen)
  26. Date: Sat, 31 Oct 87 16:05:21 CST
  27. Subject: Blinking Session
  28.  
  29.  
  30. The reason that the session blinks when the bell sounds is to identify which
  31. session the bell is coming from.  I am quite aware of the blinking menu bar 
  32. effect, but have been known to have trouble determining which window to look
  33. in when there was a beep caused by external events (especially difficult with
  34. 4+ windows).   Perhaps we should look into just blinking the session if it
  35. is not the currently active session.  Therefore, only beeps from a session in
  36. the background would blink at you.
  37.  
  38.  
  39. What do you think?
  40.  
  41.  
  42. Gaige
  43.  
  44. ---------------------------------------------------
  45.  
  46. From: gaige@ncsa.uiuc.edu (Gaige Paulsen)
  47. Date: Sun, 1 Nov 87 13:40:00 CST
  48. Subject: Keyboard remapping and Multi-Finder
  49.  
  50.  
  51.   I have been told that people are having problems with the keyboard remapping
  52. screwing up other applications under Multi-Finder.  Although I agree that
  53. it is a problem and am working on finding a nice solution, there is an interim
  54. solution to the problem.  Provided with the new system file is a new keyboard
  55. 'cdev'  this should allow you to change the keyboard back and forth as
  56. necessary.
  57.  
  58. Gaige B. Paulsen
  59. National Center for Supercomputing Applications
  60.  
  61.  
  62. -------------------------------------------------------------
  63.  
  64. From: timk@ncsa.uiuc.edu (Tim Krauskopf)
  65. Date: Wed, 4 Nov 87 17:41:52 CST
  66. Subject: How to handle nameserving of nicknames
  67.  
  68.  
  69. I would like to get some input on the use of nicknames with NCSA Telnet:
  70.  
  71. Is the presence of the CNAME field in BIND a nickname facility that we can
  72. use instead of burdening our local config files with all of the nicknames
  73. that each user wants?
  74.  
  75. Here are the choices that I see:
  76.  
  77. choice 1:
  78.   add default domain endings to non-qualified names or not.  i.e. we append
  79.   "ncsa.uiuc.edu" to the end of every short name that is typed by the user
  80.   before that name is looked up with domain name lookup.
  81.  
  82. If you do add them, then people in this building must type fully qualified
  83. names or some other strange scheme when they want to get out of the building.
  84. Or maintain those names in local host files -- same as old problem.
  85.  
  86. choice 2:
  87.   since we aren't going to add the default domain ending, where shall we
  88. maintain the list of nicknames which includes names from inside our domain
  89. and "nic" or "andrew" which are outside our domain?
  90.   Shall we put them in our individual config files or are we going to maintain
  91. a CNAME cache on our BIND servers?  I know which one is easier.
  92.  
  93. We are trying to bring up a CNAME server that takes care of our nicknames.
  94. These names would never be exported, but requests at our local servers would
  95. be honored for nicknames.  Another way to do it is support yellow pages, 
  96. but no thank you.
  97.  
  98. Any other points of view?
  99.  
  100. Tim Krauskopf
  101. timk@ncsa.uiuc.edu
  102.  
  103.  
  104.