Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97650
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>
Message-ID: <7db42b81-0fc3-c572-8ff4-55af22b60975@gmx.de>
Date: Tue, 10 Jan 2017 00:44:21 +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: <08.81.31343.C40F3785@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")

On 09.01.2017 at 21:19, Andrea Faulds wrote:

> Christoph M. Becker wrote:
>
>> Kalle raised some objections regarding the direct use of streams in the
>> API, namely that imagegifanimbegin() expects an open stream to be passed
>> as parameter, so perhaps it would be better to accept a stream URL
>> instead and manage the stream behind the scenes.  That appears to be
>> much more solid (as the developer couldn't fiddle with the stream), but
>> would require some encapsulation mechanism, either a resource, what
>> would be in line with the other GD resource types[4], or an (opaque)
>> object, what appears more suitable for PHP 7.
>>
>> Currently, I'd prefer an *opaque* object which would be created by
>> imagegifanimbegin() (creating the respective stream internally), passed
>> to imageanimadd() and be destroyed by imagegifanimend().
> 
> 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.

> 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?

-- 
Christoph M. Becker