There has been quite a bit of discussion about this recently, especially in the ql-users mailing list. So I will add my two pennies worth. My ideas are the following :
File naming structure should change. I think it would be useful to move to Unix
style directory structure. For compatibility sake, it would be best to limit "real" file name length (name including extension, excluding path) to 36 characters. This should be sufficient for all normal use. Longer names would no longer be user friendly anyway (you don't want the filename to contain the entire text of the document - that beats the purpose of naming files). Filenames should have their extension separated by a dot (yes, this is already supported in ProWesS). The
directories should be separated by a slash (/). There should be one root directory, and all the devices should be subdirectories of that (e.g. "/win1/" for what is now "win1_"). If you would ask for a directory of the root (so "dir /"), you would get all the available devices. This is a big improvement, as there is currently no clean method on the QL to know which devices are available.
All programs need local default search
path and destination directory. This can be provided by using the environment variable system which is part of c68 (and ProWesS's global variables should be replaced by that). The path can contain several directories, separated by semicolons (;) and searched from left to right.
Device driver structure could be made more generic. You can make the distinction between block oriented devices (disks etc.) and serial devices (serial and parallel port). You can have
protocols to run on top of these devices to provide specific services like talk to another computer, or use the blocks to provide a directory structure and filing system. This could be a major improvement over current systems. It would make all disk based systems behave identical, independent of whether they are interfaced by ACSI (ST/TT), SCSI (TT), Qubide, Rebel or Miracle i/f. It is currently a real problem under Qdos/SMSQ(/E) that you can not rely on a specific
error to be reported when a specific problem occurs. This depends on the producer, type and even version of the device driver.
Links should be supported. For example "/prg/" could then be a link to the "/win1/prg/" directory. Alternatively the file "/win1/prg/LINEdesign" could be a link to the "/win1/development/applications/LINEdesign/LINEdesign".
In the resolution of filenames and paths, it always has to be possible
to use environment variables. They can normally be referenced by including "$VARNAME". The name can be terminated by a slash or dot or another dollar sign.
I have already mentioned that each program should have a local path and destination. These should be inherited from the calling program, but still be local. When a filename starts with a slash then the filename includes the complete path. If the filename does not start with a slash then the place to
search depends on the action. When you open an existing file, it should be searched on the path. If you open for writing, it should be opened on the destination.
The file system should also support the "." and ".." conventions. Using "..", you can move a directory up in the path, so "/win1/mine/../" is the same as "/win1/". The dot is a current directory indicator. When used at the start of the path (e.g.
"./output.txt") it should reference the destination, even when opening for reading. When it occurs in the middle, it should be skipped, so "try/./this.txt" is the same as "/try/this.txt".
It would be useful if the file header includes an extra field which indicates the producer of the program. This could be used to automatically call the producer program when you execute a file. This is similar to the FileInfo linking of file extensions to programs, but without the problem that an extension could be used by several programs. Of course the handling of FileInfo would still be useful when the requested program is not available.
