home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / x / 19416 < prev    next >
Encoding:
Text File  |  1992-11-20  |  2.8 KB  |  65 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!think.com!snorkelwacker.mit.edu!bloom-beacon!INTERNET!dont-send-mail-to-path-lines
  3. From: samborn@mtkgc.COM (Kevin Samborn)
  4. Subject: Re: Programming resource management
  5. Message-ID: <9211201440.AA18999@mtkgc.COM>
  6. Sender: root@athena.mit.edu (Wizard A. Root)
  7. Organization: The Internet
  8. Date: Fri, 20 Nov 1992 14:40:24 GMT
  9. Lines: 54
  10.  
  11. > The X window system resource management software is very appealing for use
  12. > in designing configuration management information.  I am wondering what
  13. > packages , commercial or otherwise, are available for managing resources
  14. > in a similar manner exist.  The base software will primarily be C or C++.
  15. > The software which needs to be configured would all be 'home-grown' so that
  16. > integrating the details into vendor software will be a lower priority.
  17. > 
  18. > Dependance on an X server in existance is not desired.  Obviously some sort
  19. > of database management software will be needed, as well as software to
  20. > update, override , handle classes, document, etc.
  21. > 
  22. > Is there a better group of which to ask this question?
  23.  
  24. It is interesting that you mentioned this.  I feel it is a oversight on
  25. the part of the X Consortium for not handing out the resource manager
  26. as a separate module.  This is one of my biggest gripes right now.
  27.  
  28. Especially with the advent of other "Workstation Control" servers, like
  29. audio, agent-style daemons, etc.  There will often be "$DISPLAY"
  30. oriented processes that do not use X.  As you mentioned, it is
  31. unreasonable to expect them to make use of the X resource manager.
  32. However, it is also unfortunate to replicate code.
  33.  
  34. What I would personally prefer is that the X server, and Xlib have
  35. "plug and play" modules (via dynamic linking and hooks?) for things
  36. like resource management.  How does CLX and other alternative language
  37. bindings handle resource management?  Are they wrappers around Xrm?
  38.  
  39. Another thing is the dependency on the DISPLAY environment variable to
  40. find out where a user is sitting.  Are audio-only daemons supposed to
  41. use the DISPLAY variable to find out the "input devices/output devices"
  42. combination?
  43.  
  44. One last thing: people tend to start their X server as the last thing
  45. when they log in.  This kind of makes the X server the "most important"
  46. process.  By terminating the X server, the X IO error handlers kill X
  47. processes that are still hanging around.  So this path follows:
  48.  
  49. Login -> shell -> X server { clients } -> logout
  50.  
  51. What about the audio servers?  If people exec the X server, how does
  52. one terminate the audio server if it is not an X client?
  53.  
  54. I think we need a "Workstation Control Server" that starts and
  55. maintains all the daemons/servers for a particular user at a particular
  56. "output devices/input devices" station.  Kind of like an inetd for
  57. X/audio/etc.
  58.  
  59. kevin samborn
  60. --
  61. kevin samborn
  62. sakura global capital
  63. samborn@mtkgc.com
  64.  
  65.