On Sun, 16 Jan 2005 10:39:36 -0000, jms1 <[EMAIL PROTECTED]> wrote:
I support Wolfgang in making very clear what is to be achieved before designing the specification.
There seem to be three problems to my mind.
1. The problem of a program finding its own information such as configuration and help files. 2. The problem of a program knowing where to write the data. 3. The problem of deep directory trees being limited by the QL file name length.
Any solution to my mind must be 1. Be compatable with existing QLs 2. Be the same for all devices. 3. As far as possible be as similar as possible to existing QL usage.
Problems 1 & 2 would seem to be solved by Configuration blocks
I suggested as an alternative passing parameters -p & -d for program data directories.
George Gwilt already uses the second solution in some of his programs.
Hence the suggestion to adapt present programs where possile or include both.
But this makes it awkward - we should no longer be relying on the users to set up the correct entries in their boot program to ensure that the correct parameters are passed to a program for their system (or expect the user to configureteh program every time a new version is released). You also have the problem of programs being launched from within the QPAC 2 files menu, where no parameters are passed (or are forgotten).
This is why it is much simpler to allow a program to interrogate a system wide block to check on the directory from where it was launched.
The other standard method is paths for which there is already an extension which I ought to investigate and probably use.
For directory changing prog_use, data_use, dup & ddown are the standard QL comands.
They are to mind adequate if QL specific and hence I see no reason to change them.
DATAD$ is equivalent home directory anyway.
Yes, I agree that these would be fine for our purposes IF IT WERE NOT FOR ONE PROBLEM.
PROG_USE and DATA_USE are system wide settings and cannot vary between programs. If you launch one program it could read the current PROG_USE and DATA_USE settings at the time that it is started, but again, you have to presume that the user is going to alter these every time that a program is started. This is not exactly user friendly.
So the real problem is 3 deep directory structures. As I understand it the present directory system hides files with names containing the file name of the directory when using the command dir or wstat. mkdir makes a directory file.
So if the system is to be compatable it has to respond the same on 'old'
QLs.
Hence the suggestion of adapting the present system.
Perhaps the present directory name could be replaced by a two bytes so that
win1_sys_bin_net_peek becomes win1_ac_bc_net_peek. Directory file win1_sys_
appears as win1_ab_ on an old QL and directory file win1_sys_bin_ appears as
win1_ab_bc_ Or less transparently but enabling deeper directories win1_bc_
represents win1_sys_bin_.
By this means near backward compatability could be maintained.
I think I see your point here - are you suggesting a lookup table for directory names on the new system.
This would just make things extremely complicated to use since how would the programmer know where to look especially when they are trying to do something like copy all files from win1_ to win2_ (and copy all the directory structure across as well).
The easiest way is to implement a new standard, with a different file type for the directory files. Programs which do not understand the new directory structure would then ignore the directory names and have to use whatever paths they can find (isn't this going to be a problem)? On standard QL systems, the programs would have to adopt to using the old directory structure only and the user will be limited to using the 41 character filename limits.
<<cut>>
-- Rich Mellor RWAP Services 26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ
http://www.rwapservices.co.uk/
_______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
