Richard Hainsworth wrote:
I think this is a much more flexible system than those suggested so far. It seems to me that this approach - lets the OS and the implementation deal with pathways that are valid (taking into account locale and OS constraints). - defines only that part of the location/directory tree/file system on which perl6 programs operate, rather than having to understand the whole environment in which software could run - delegates to a module if perl6 is to be used to manage a specific environment/OS - offers more future proofing and portability than constraining what can or cannot be in a pathname. - allows users to configure via Policy.pm standard pathnames to something non-standard for development and testing, leaving the software itself unchanged.
Richard, thanks for your feedback. I think you raise a lot of good points about further consequences of my proposal.
I think I'll also raise the point that depending on how its further designed, my proposal could help with security as well, by implicitly defining sandboxes as it were.
If it is interpreted that you can not refer to something that is a parent or sibling dir of a DOI by way of that DOI, hence treating it like an absolute root, then that means that any code can only access parts of the filesystem that are visible-to-it DOIs or subdirs of said, because there's simply no syntax to reference anything outside. There is no '..' in my scheme.
For example, if a Perl thread starts out seeing only a single DOI representing the filesystem root, and they update it to some subdir, then they have just chrooted themselves.
Similarly, if a Perl thread does not see any DOI at all, then they effectively are denied access to the filesystem period.
So in general, I hope people can see that a natural consequence of my proposal is that we also have an elegant means for security or virtualization, which among other things can aid Perl's support for running in restrictive environments, such as a "cloud", or whatever.
Note, I want to make clear that my proposal is *not* about abstracting away all kinds of IO into a single uri scheme, but only abstracting the file system. Not that it can't be further extended in appropriate ways.
-- Darren Duncan
