From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,942b3184b8c0c422
X-Google-Attributes: gid103376,public
From: kilgallen@eisner.decus.org (Larry Kilgallen)
Subject: Re: Platform portable support of heir. file systems
Date: 1996/12/19
Message-ID: <1996Dec19.075644.1@eisner>#1/1
X-Deja-AN: 204907483
x-nntp-posting-host: eisner.decus.org
references: <01bbec7f$453edcd0$24af1486@pc-phw> <1996Dec18.071612.1@eisner>
 <59b6ea$522@top.mitre.org>
x-nntp-posting-user: KILGALLEN
x-trace: 851000212/28101
organization: LJK Software
newsgroups: comp.lang.ada
Date: 1996-12-19T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <59b6ea$522@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:

> IMO we should standardize a set of machine independent operations on
> URLs that are equally applicable to all major operating systems, yet
> raise the correct exceptions when, for example, someone puts spaces
> in the middle of a filename on a system that prohibits unquoted spaces,
> such as during ftp to Windows NT or Macintoshes. The facts (VMS has
> generational datasets while NT does not, various systems have different
> limitations, DOS is limited to 8.3 characters, devices are handled
> differently, and quotation characters are incompatible: double quotes
> versus backslash versus single quotes) do not prevent standardization 
> of a URL object that will handle the common aspects of file systems. 
> 
> The following is a strawman proposal to start discussion of such
> a standard visible part, (whose body would be implemented using 
> existing Ada-95 facilities, annexes, and interfaces). 

OK with me, but someone else may kick us off c.l.a due to bandwidth
consumption.

> package url_control is

The letters "url" already have a meaning as "universal resource locator"
in HTTP, and although on some Unix systems they may correspond to a
file system structure that is by no means required in the HTTP world.
The only requirement is that retrieval of information "works" according
to the HTTP rules.

Thus, I feel overloading the term "url" with something which _does_
correspond to real OS files is a bad idea.

>   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)?

>   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 ?
(Purists would say creating it in the first place is not an
acceptable side-effect for a function.)

>   type systems is (default_system,
>                    compatible_system,
>                    fruit_system,
>                    open_system,
>                    vegetable_system);
> 
>   procedure set_system (system: systems); 
>   function system return systems;

Hmmm:

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

>   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.

>   function file_name_separator   (system: systems := default_system)
>                                   return character;
> 
>     -- File name separator might be a period or slash depending on
>     -- the operating system.

Ok, but I don't see "directory start" or "directory end" characters,
([,],<,> on VMS but always matched) such as:

    DISK$QUENTIN_73:<LARRY.ADA_STUFF.DISCUSSIONS.FILES>PROPOSAL.TXT;24
or
    $213$DUA7:[ADA$PREDEFINED_ROOT.SYSCOMMON.SYSLIB.][ADALIB]$STANDARD_.ADC;1

>   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",
so expanding those routines to support VMS semantics without
introducing VMS terminology, how about:

	type level is (innermost, inner, outer, outermost);

	function environment (
	                variable : in String;
	                variable_index : in Natural;
	                case_sensitive : in Boolean;
	                environment_table : in String;
	                environment_table_level : in level ) return string;

	procedure set_environment (
	                variable : in string;
	                value : <this really needs to be an array-of-strings>;
                        environment_table : in String;
                        environment_table_level : in level;
	                copy_on_spawn : in Boolean;
	                susceptible_to_outer_level_alias : in Boolean;
	                conceal_contents : in Boolean;
	                terminate_recursive_translation : in Boolean);

Larry Kilgallen