Re: Platform portable support of heir. file systems

[mfb@mbunix.mitre.org (Michael F Brenner)]

>> package url_control is
>The letters "url" already have a meaning as "universal resource locator"
>in HTTP

The url_control package is using url as universal resource locator, but
is not restricted to being used by http. For example, it is often used 
for ftp. In addition, it contains a filename, and with certain portions
of the url blank, it IS a filename. Thus this package is used both on
a local computer and across the net. In other words, the word url is 
not being overloaded. It Already has the meaning of being a filename.


>> function directory_get_first (pattern: urls) return urls;
>> function directory_get_next   return urls;
> "Next" using the last pattern used ?  In what context ?  How does one
> distinguish one directory search from another (comparing the contents
> of two directories, for instance)?

Sorry, my telepathy did not transmit through well enough. This is a good
argument for finding a way to put more semantic information into
visible parts before Ada-2005 is created. You only have to give the pattern
once. Get_first and get_next are like an interator which continues until
the url returned is the null string, which means there are no more 
entries in the current directory which match the pattern. This is the way
DOS provides access to the directories to avoid data structures that
force you to read the entire directory into memory at one time so 
something like an object-oriented iterator would be useable, but at the
expense of a large amount of wasted RAM.

>>   function directory_temp return urls;
> Unique to this thread or just to this executable program ?
> Shouldn't there be a matching call to delete it ?

Again, sorry for the missing semantic information. In DOS the temporary
directory, where the users may create subdirectories which will be 
deleted by the disk manager, say, every Friday, is called \TMP. In Un*x,
the temporary directory is called /tmp. The string \TMP, /tmp, or 
[SYS001.tmp] would be returned by function directory_temp. What would
be created and deleted would be subdirectories underneath the temporary
directories.

         if system = dos_system
        then
                set_system (unix_system);
        end if;

Code like this would make sense in writing an application like
dos2unix. If we are in DOS (which uses carriage return-line feed) 
and we wish to convert the file to Un*x (which uses line feed only),
then we would set_system, so the next file_instantiation.put_line
would append the Un*x end_of_line_string to the end of the line 
instead of the DOS end_of_line_string. 


>> function end_of_line_string (system: systems := default_system)
>>                              return string;
>Since the "url" is an Ada string, I presume this must refer to some
>sort of separator within a file.  That is a very Unix (or is it C?)
>chauvenist approach.  By default, VMS files have no such element,
>and I would doubt that MVS files do either.  A record is a record,
>delimited by out-of-band mechanisms private to the operating system.

I used and respected VMS for years with the exception of a component
called the Record Manager. The Record Manager does not deal with files
as arrays of characters; IMO this is a design flaw of the Record Manager.
When I used DEC Ada it took quite a bit of effort to bypass the Record
Manager, using Starlet channel programs, interfaces to assembler, and other
tricks which should not have been necessary, in order to see the files 
as arrays of characters. 

Because so many Defense contracts used vaxen (11-780s or LSI-22s),
text_io was made to follow the Record Manager, instead of the idea
that a file is just and array of bytes. IMO, this is very serious
design flaw of text_io, a flaw which irks most newcomers to the 
language the first time they try to do random access on a text file
or rewind standard_input. There is no valid theoretical reason for
denying ordinary operations on files just because Record Manager
denied them. The packages that import url_control should support
files which act like an array of characters, which is the default
for operating systems that are DOS, NT, or Posix-compatible; if they
support the Record Manager, that should be In Addition To, not instead
of the array of characters operations. Is this Un*x- or DOS-chauvenistic?
No, to follow the Record Manager would be chavenistic, because I am
not restricting any of the Record Manager operations, but it is a great
inconvenience to restric file users to Record Manager operations.

> I don't see "directory start" or "directory end" characters,
VMS requires square brackets around directory names, and that could
be accomplished automatically whenever an operation was done with
system equal to VMS, which would make the separator a period, and 
automatically add the square brackets. Externally, the square brackets
would not necessarily be stored in a url, because transmitting it
across the net would not always work (for example, certain Un*x 
shells would have problems). 

> Your Unix is showing :-).
Yes, but it is identical in un*x, DOS, NT, etc. Again, the only outlier is
VMS. And VMS is now Posix compliant and is capable of running Posix shells
at user request. Yes, I realize that this argument can be turned around,
and DOS can run a VMS shell, so yes, absolutely yes, my Unix is showing,
and I am demonstrating a preference for a syntax that satisfies me on
almost all operating system shells, rather than all shells.


>> function environment (variable: string) return string;
>> procedure set_environment (variable: string; value: string);
> Your Unix is showing :-). Presuming the goal is to deal with things
> which affect file access, on VMS that would be "logical names",

People have remarked that environment variables work differently on VMS
and Unix and DOS. I think this is wrong, because only DOS actually has
environment variables. Unix has the capability of running a shell that
has environment variables which are more powerful than DOS environmental
variables, but most Unix shells do not give the programmer this capability.
In all operating systems, there is a way to give the programmer a
machine independent capability to set global environmental variables,
using a shared file and an application (object, TSR, process, or whatever)
that manages that shared file. The question is not how we are going to
spell the capability in each operating system. The question is how will
we provide the programmer with a machine independent capability of 
sending messages to the other programs in the machine. Stating that 
something called environmental variables works differently in VMS is
not solving the problem. The set_environment and environment together
define the interface for a machine independent facility that should be
provided. How we provide it is a separate (but important) question.

You suggested environment_table and environment_table_levels as 
interfaces are interesting. What do the levels mean?

mikeb@mitre.org