Re: Proposal: php://memory/<id> (& ://temp/<id>)
| From: | Ivan Enderlin @ Hoa | Date: | Thu, 31 Jan 2013 13:55:26 +0000 |
| Subject: | Re: Proposal: php://memory/<id> (& ://temp/<id>) | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-65540@lists.php.net to get a copy of this message | ||
On 31/01/13 12:18, Gustavo Lopes wrote:
On Thu, 31 Jan 2013 10:37:53 +0100, Ivan Enderlin @ Hoa <ivan.enderlin@hoa-project.net> wrote:The php://memory, and its respectful sibling php://temp, appear very useful when we need to compute streams on-the-fly. They offer a lot of services, like avoiding HDD accesses, increasing speed... and through a straightforward API /à la/ PHP, e.g. fopen('php://memory', 'r+'). However, we always work on the same "bucket"/space of data (per runtime), which prevent us to use two different streams at a time. My proposal is to allow access to many "buckets"/spaces to php://memory and its sibling.I'm not sure what you mean here. Each time you open a php://memory stream, you're working on a new "bucket", right? Yes exact. My bad. But my proposal still persist. Identifying php://memory buckets would be nice to retrieve them. For example:
$f1 = fopen('php://memory/foo', 'r+');
fwrite($f1, 'foobar');
unset($f1);
$f1prime = fopen('php://memory/foo', 'r+');
rewind($f1);
var_dump(stream_get_contents($f1)); // string(6) "foobar"
Is it interesting? In this way, we have a similar behavior than php://fd/<i>, file://, http:// etc.
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/