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
