perltodo tweak on virtualizing OS/FS access

diff --git a/pod/perltodo.pod b/pod/perltodo.pod

index 6b7a089..48acd2c 100644 (file)
--- a/pod/perltodo.pod
+++ b/pod/perltodo.pod
@@ -636,25 +636,30 @@ Implement a set of "vtables" that virtualizes operating system access
 (open(), mkdir(), unlink(), readdir(), getenv(), etc.)  At the very
 least these interfaces should take SVs as "name" arguments instead of
 bare char pointers; probably the most flexible and extensible way
-would be for the interfaces to accept HVs.  The system needs to be
-per-operating-system and per-file-system hookable/filterable
+would be for the Perl-facing interfaces to accept HVs.  The system
+needs to be per-operating-system and per-file-system
+hookable/filterable, preferably both from XS and Perl level
 (L<perlport/"Files and Filesystems"> is good reading at this point,
 in fact, all of L<perlport> is.)
 
-A less ambitious form of this has actually already been implemented
-(but only for Win32), take a look at F<iperlsys.h>.  While Win32
-systems go through a set of "vtables" for operating system access,
-non-Win32 systems go straight for the POSIX/UNIX-style system/library
-call.  Similar system should be implemented for all platforms.
-The existing Win32 implementation probably does not need to survive
-alongside this proposed new implementation, they could be merged.
+This has actually already been implemented (but only for Win32),
+take a look at F<iperlsys.h> and F<win32/perlhost.h>.  While all Win32
+variants go through a set of "vtables" for operating system access,
+non-Win32 systems currently go straight for the POSIX/UNIX-style
+system/library call.  Similar system as for Win32 should be
+implemented for all platforms.  The existing Win32 implementation
+probably does not need to survive alongside this proposed new
+implementation, the approaches could be merged.
 
 What would this give us?  One often-asked-for feature this would
 enable is using Unicode for filenames (and other "names" like %ENV,
 usernames, hostnames, and so forth.)  But this would also allow for
-things like virtual filesystems and "sandboxes" (though as long as
-dynamic loading of random object code  is allowed, not very safe
-sandboxes since external code of course know not of Perl's vtables).
+things like virtual filesystems, virtual networks, and "sandboxes"
+(though as long as dynamic loading of random object code is allowed,
+not very safe sandboxes since external code of course know not of
+Perl's vtables).  An example of a smaller "sandbox" is that this
+feature can be used to implement per-thread working directories:
+Win32 already does this.
 
 =head1 Big projects