home *** CD-ROM | disk | FTP | other *** search
/ vsiftp.vmssoftware.com / VSIPUBLIC@vsiftp.vmssoftware.com.tar / FREEWARE / FREEWARE40.ZIP / flistfrontend / doc / da.rno < prev    next >
Encoding:
Text File  |  1995-10-23  |  4.5 KB  |  113 lines
  1. .; $Id: da.rno,v 1.2 1995/10/23 20:36:52 tom Exp $
  2. .req    "d0.req"
  3. .;
  4. .;
  5. .hl    Goals
  6. The design goal for FLIST is to implement a full-screen interface to
  7. VMS which never hinders, but always aids the user.
  8. FLIST's design is influenced by three related programs:
  9. .lm+8
  10. .b.i-4
  11. o    EDT, the default VMS text editor is easy to learn and use
  12. because its most useful operations are provided on the keypad.
  13. The FLIST's keypad is modeled after EDT's so that an EDT
  14. user may easily use FLIST.
  15. FLIST's keypad operations fall into three categories:
  16. .lm+8
  17. .b.i-4
  18. -    Directory sorting and other display modification
  19. .b.i-4
  20. -    Status (_?TIME), inspection (BROWSE, VIEW), editing
  21. .b.i-4
  22. -    Searching and scrolling
  23. .b.lm-8
  24. The EDT design model uses the keypad for the operations which are
  25. both most frequently used, and which require the least auxiliary
  26. (argument) information.
  27. .b.i-4
  28. o    FLIST (a directory editor running on IBM VM/CMS) represents
  29. the ultimate in performance.
  30. Unlike VMS and Unix, on CMS disk directories reside in virtual memory.
  31. By paying an initial "access" overhead, each user possesses a copy of
  32. each disk directory which can be rapidly interrogated and modified.
  33. FLIST runs much faster than any similar program could on VMS or Unix
  34. for this reason.
  35. .b.i-4
  36. o    DIRED (a simple directory editor on Unix)
  37. shows that a directory editor can run on medium-sized systems.
  38. .b.lm-8
  39. FLIST is not a copy of either FLIST or DIRED.
  40. It is implemented in a more difficult environment than either,
  41. because of complications imposed by VMS file structures:
  42. .lm+8
  43. .b.i-4
  44. o    FLIST runs (as noted above) in an environment which provides
  45. ready access to the directory.
  46. Each and every filename is composed of three tokens (name, type and disk).
  47. Screen management is performed by a fully integrated display manager.
  48. .b.i-4
  49. o    DIRED runs on a system which is superficially similar to VMS.
  50. Filenames are hierarchical.
  51. Very crude display management is done, since this is done by each program.
  52. .lm-8
  53.  
  54. .hl Tradeoffs
  55. VMS is more complex than Unix because its file structure is not
  56. as simple to parse.
  57. On Unix there is no syntactic difference between filenames and directory
  58. names.  This is not the case on VMS.
  59. .b
  60. Wildcard expansion must be done via the program, rather than automatically
  61. by the shell.
  62. While RMS routines are available for processing wildcard lists,
  63. a list of file specifications must be additionally processed by
  64. CLI routines (or their equivalent).
  65. .b
  66. Version numbers are especially troublesome.
  67. Neither Unix nor CMS uses them; each filename is unique.
  68. Version numbers complicate FLIST.
  69. For example, a user may wish to delete the highest version of a file
  70. which appears with more than one version.
  71. FLIST must do the deletion immediately, else in succeeding operations
  72. the user may edit the "highest" remaining version (resulting in a
  73. version conflict).
  74. Thus FLIST is a what-you-see-is-what-you-get editor.
  75. .;
  76. .hl+1    Terminal Control
  77. Screen management is done within FLIST, using the
  78. low-level screen routines (erase, write, index) provided by VMS.
  79. Presently, no screen package is provided on VMS which can be used
  80. to adequately represent a dynamic display such as FLIST's.
  81. To provide compatibility with both VT52 and VT100, a single display
  82. window is used (VT52 doesn't support scrolling margins).
  83. .;
  84. .hl    Running DCL Commands
  85. FLIST performs most of the essential file-management commands internally.
  86. The remainder (COPY, EDIT) are performed by a process spawned for each command.
  87. While this is simple, it is slow, particularly file-copying:
  88. .lm+8
  89. .b.i-4
  90. o    FLIST parses the command, using RMS to parse the file specifications.
  91. RMS must do I/O to support its parse.
  92. .b.i-4
  93. o    FLIST verifies that the output file is writable,
  94. requiring more I/O, and determines its name.
  95. .b.i-4
  96. o    After the spawned command is completed, FLIST searches for
  97. the resulting file to append its entry to the display list.
  98. .b.lm-8
  99. In short, FLIST both preprocesses and postprocesses spawned commands
  100. to determine their effect.
  101. To avoid this completely, one would have to embed the code to perform
  102. all VMS commands within FLIST.
  103. This is neither desirable nor feasible.
  104. .;
  105. .hl    Interface to CLI and Error Reporting
  106. FLIST performs its own command parsing to circumvent the VMS error-message
  107. facility, as well as to provide a good base for the command pre/post-processing.
  108. The problem with the VMS error facility is that it does not permit
  109. programs to capture the message-text.
  110. Because FLIST must display a large variety of command syntax
  111. and usage errors in a relatively controlled fashion,
  112. it does the entire job itself.
  113.