Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:40939 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91348 invoked from network); 11 Oct 2008 19:30:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Oct 2008 19:30:58 -0000 Authentication-Results: pb1.pair.com header.from=greg@chiaraquartet.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=greg@chiaraquartet.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error) X-PHP-List-Original-Sender: greg@chiaraquartet.net X-Host-Fingerprint: 208.83.222.18 unknown Linux 2.6 Received: from [208.83.222.18] ([208.83.222.18:59562] helo=mail.bluga.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AE/C8-46613-1FEF0F84 for ; Sat, 11 Oct 2008 15:30:58 -0400 Received: from mail.bluga.net (localhost.localdomain [127.0.0.1]) by mail.bluga.net (Postfix) with ESMTP id ADA1CC10466; Sat, 11 Oct 2008 12:30:53 -0700 (MST) Received: from [192.168.0.106] (unknown [76.84.4.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bluga.net (Postfix) with ESMTP id 575C5C10465; Sat, 11 Oct 2008 12:30:53 -0700 (MST) Message-ID: <48F0FF54.7020303@chiaraquartet.net> Date: Sat, 11 Oct 2008 14:32:36 -0500 User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Marcus Boerger CC: internals Mailing List References: <48F0E625.9050505@chiaraquartet.net> <1412443725.20081011205750@marcus-boerger.de> In-Reply-To: <1412443725.20081011205750@marcus-boerger.de> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [PHP-DEV] question on how to solve major stream filter design flaw From: greg@chiaraquartet.net (Gregory Beaver) Marcus Boerger wrote: > The filters need an input state and an output state. And they need to > respect the the fact that number of requested bytes does not necessarily > mean reading the same amount of data on the other end. In fact the output > side does generally not know whether less, the same amount or more input is > to be read. But this can be dealt with inside the filter. However the > filters should return the number input vs the number of output filters > always independently. Regarding states we would be interested if reaching > EOD on the input state meant reaching EOD on the output side prior to the > requested amount, at the requested amount or not at all yet (more data > available). Hi, All of this makes sense, but how to implement it? Currently, there is no clear way to answer questions like: 1) how much data did the filter consume, and how much is left over? 2) how much data is left in the original stream prior to filtering? Perhaps this could be implemented by overloading ftell() so that it can accept a filter resource as well as a stream resource? Also, a new function could be implemented: stream_filter_datasize(resource $filter) // I'm open to better names that would either return the total size of filtered data available, or false if this is indeterminate. This would allow: Greg