>On 31/01/13 12:00, Sebastian Krebs wrote:
>> 2013/1/31 Chris Wright <chr...@aquacool.ltd.uk>
>>
>>>> I propose the following syntax:
>>>>
>>>> php://memory/<id>
>>>> php://temp/<id>/maxmemory:<size>
>>> I would very much like to see this as well.
>>>
>>> Would this also allow you to open multiple pointers to the same bucket?
>>>
>>> For example would this work?
>>>
>>> <?php
>>>
>>> $fp = fopen('php://memory/foo', 'w+');
>>>
>>> file_put_contents('php://memory/foo', 'data');
>>>
>>> rewind($fp); // would this be necessary?
>>>
>>> echo stream_get_contents($fp); // outputs 'data'
>>>
>>
>> Everything else wouldn't make much sense, because why else should you
>> need to define an id for it?
>>
>> Bu whats about
>>
>>
>> file_put_contents('php://memory/foo', 'data');
>> $fp = fopen('php://memory/foo', 'w+');
>>
>> 'file_put_contents()' closes the stream after writing. I would expect,
>> that the engine will cleanup the memory (at least sooner or later),
>> but then I open it again.
> Yup, I also expect the engine to clean memory when closing php://memory or
> php://temp, but this
> is another proposal I think, no?
>> Additional why don't you just pass the open stream around, if you need to
>> access it at multiple places?
> Is this question for me or Chris? If it is for me, I don't want multiple
> accesses to the same "bucket"/space, I want multiple "buckets"/spaces.
My thinking was for stuff like ZipArchive, which does not accept streams, only
paths. As it is
there is no way to use ZipArchive entirely in memory, you have to write it to
disk (it also currently
cannot cope with URLs so this alone would not fix it, but that's another
story). I admit the use case
is narrow, but I do have a specific case where I need to post-process the
resulting data before
outputting/writing to the final file, this functionality would be a step
towards working around this.
I'm sure there are other examples of this as well.
As ALeX pointed out, there are other ways to work in this manner using custom
stream wrappers, and if
it would be too difficult/wouldn't make sense to the engine to do this, then so
be it :)
Best Regards
Chris Wright
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
