Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97746
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <2cee1fe1-6dfd-0337-7286-42f873b9f508@gmx.de>
 <08.81.31343.C40F3785@pb1.pair.com>
 <7db42b81-0fc3-c572-8ff4-55af22b60975@gmx.de>
 <0F.87.55699.8E435785@pb1.pair.com>
Message-ID: <e915aeda-6a47-72cd-20f4-e0964b8f91fb@gmx.de>
Date: Fri, 13 Jan 2017 18:56:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <0F.87.55699.8E435785@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: ext/gd: support creation of animated GIFs
From: cmbecker69@gmx.de ("Christoph M. Becker")

Hi!

On 10.01.2017 at 20:24, Andrea Faulds wrote:

> Christoph M. Becker wrote:
>
>> On 09.01.2017 at 21:19, Andrea Faulds wrote:
>>
>>> Would this opaque object still allow you to use an arbitrary stream of
>>> your choice?
>>>
>>> Also, like with imagepng() etc., could you stream the output to uh…
>>> PHP's default output stream? (I'm not sure what it's called. The thing
>>> that `echo` goes to.)
>>
>> It would be possible to allow either a stream URL or a stream to given,
>> what would fit to image(png|jpeg|…)().  However, these are "stand-alone"
>> functions which close the stream when they're finished, while the
>> animated GIF writing functions would *allow* the stream to be
>> manipulated by the userland developer, even though I can't see practical
>> reason to do so.
>>
>> And, of course, we could also let the functions accept NULL to directly
>> write to stdout.  Passing in 'php://stdout' should have the same effect.
> 
> Alright.
> 
>>
>>> If it does both, I don't have much objection.
>>>
>>> Mind you… is it really necessary to hide the stream from the user?
>>> fopen() is not particularly hard to use, and there are (admittedly
>>> niche) cases where you might want to handle the stream yourself.
>>
>> Are there really such cases?  Should we sacrifice the safety of internal
>> stream handling to support some (hypothetical?) use cases?
> 
> In fairness, I'm not sure. I know animated GIF streaming has been tried
> before, though I doubt if it's actually used at all these days. A more
> reasonable case might be embedding an animated GIF in other binary data.
> But that's a hypothetical.

Okay.

> What is the actual “safety” gain of not using streams? That you don't
> need to use fopen() yourself? (PHP will close files for you.) I'm just
> not super convinced there's a need for adding this extra layer.

It's not about having to fopen() the stream – in my opinion at least
that's a non-brainer.  What is a minor issue though, is that either
imagegifanimend() closes the stream automatically (what imagepng() and
friends are doing), or not (in my opinion the proper solution, but
inconsistent).  The major issue for me would be the possibility that the
user fiddles with the stream between imagegifanimbegin() and
imagegifanimend() – in the worst case closing the stream, so
imagegifanimend() would fail or had to catch that.  Of course, that
would be a programmer error, but nonetheless it would have to be
documented, and I'm pretty sure that at least some devs would walk into
this trap.

Anyhow, thanks for the feedback.  I'll see how to unify this in a single
RFC (probably with secondary voting options).

-- 
Christoph M. Becker