Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

On Sun, Aug 13, 2000 at 07:54:34AM -0400, Chaim Frenkel wrote:
> >>>>> "JH" == Jarkko Hietaniemi <[email protected]> writes:
> 
> JH> I agree with Dan: people do seem to get into "have to" mode awfully
> JH> soon and easily.  The proposed framework is supposed to make it easy
> JH> to handle file names and make Perl internals (well, not internal-
> JH> internals, but the IO layer) better support multiplatform situations,
> JH> both when scripts have to run on multiple platforms, and when
> JH> an application is running on multiple platforms _simultaneously_,
> JH> servers-clients, peers-peers, etc.
> 
> Fine. Then all the 'parts' of a generic filename (or should that be
> a resource name) are pure strings?

Unicode strings.

> Who supplies the logic to scrunch them together into an understandable
> (to the os) form?

The IO layer.  Look at the File::Spec code now.

> And how do we make it easy to pass in a name to open?

I am talking of *internal* representation, not something visible from
the Perl level.  Something core hackers and porters to platform FooBar
would see.  Not something even necessarily XS (or the son-of-XS) would
see unless they need and want to.

> 	$fh = open Perl::Canonical(Host=>"remote"
> 				    ,OS=>"VMS"
> 				    ,Device=> "DAO"
> 				    ,Path=>("path", "to", "resource")
> 				    ,Name=> "filename"
> 				    ,Type=>"txt"

No.  Type is not part of the name (in the generic case, and this whole
thing is about genericity).  Did you mean "extension" or "suffix"?

> 				    ,Version=> ":oldest"

Versioning is a very hairy thing (especially if we branch out of
OS level to application level: Emacs, RCS, other versioning control
schema).

> 				);
> 

-- 
$jhi++; # http://www.iki.fi/jhi/
        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen