From e1a3d5d19d05711208a4ddce62cf9b660067e1ff Mon Sep 17 00:00:00 2001 From: Jarkko Hietaniemi Date: Tue, 29 May 2007 09:50:57 +0300 Subject: [PATCH] perltodo tweak on virtualizing OS/FS access Message-Id: <200705290350.l4T3ovWG275103@kosh.hut.fi> p4raw-id: //depot/perl@31297 --- pod/perltodo.pod | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/pod/perltodo.pod b/pod/perltodo.pod index 6b7a089..48acd2c 100644 --- 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 is good reading at this point, in fact, all of L is.) -A less ambitious form of this has actually already been implemented -(but only for Win32), take a look at F. 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 and F. 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 -- 2.7.4