Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:15418 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20039 invoked by uid 1010); 13 Mar 2005 16:30:10 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 20024 invoked from network); 13 Mar 2005 16:30:10 -0000 Received: from unknown (HELO zend.com) (127.0.0.1) by localhost with SMTP; 13 Mar 2005 16:30:10 -0000 X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from ([80.74.107.235:59596] helo=mail.zend.com) by pb1.pair.com (ecelerity HEAD r(5124)) with SMTP id A7/22-31540-F8A64324 for ; Sun, 13 Mar 2005 11:30:08 -0500 Received: (qmail 4411 invoked from network); 13 Mar 2005 16:30:04 -0000 Received: from shire.zend.office (10.1.2.160) by internal.zend.office with SMTP; 13 Mar 2005 16:30:04 -0000 Date: Sun, 13 Mar 2005 18:30:04 +0200 (IST) X-X-Sender: frodo@shire.zend.office To: Wez Furlong cc: Zeev Suraski , PHP Development In-Reply-To: <4e89b42605031308227861a559@mail.gmail.com> Message-ID: References: <4e89b42605031010124c2a4092@mail.gmail.com> <4e89b42605031012432aac07ae@mail.gmail.com> <4e89b4260503111229565d2a15@mail.gmail.com> <4e89b42605031307013841d59@mail.gmail.com> <4e89b42605031308227861a559@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] zend_stream_fixup From: stas@zend.com (Stanislav Malyshev) WF>>This is frustrating (and annoying). It's a simple abstraction layer WF>>so that the zend engine can efficiently parse input from arbitrary WF>>data sources, including, but not limited to, php streams. OK, now we are getting somewhere. The problem is that this abstraction is used in one (1) place over whole engine _and_ it abstracts it so much that leads to the situation that any extension wanting to work with file_handle beyond single operation of read cannot do so. WF>>If you told me exactly what you're trying to do, we can work together WF>>more productively. I'm trying to work with file_handle, e.g. seek it, stat it, probably something elase in the future. WF>>Instead, you've got some secret code that needs to do something WF>>magical with the stream; you won't tell me what that is, and you don't Nothing macical, just handlers implemented by php_stream, like stat and seek. And, of course, provided by stdio. WF>>If you would ask useful, practical questions, like "I need to be able WF>>to stat the stream and perform operations X, Y, Z; how can we I know how to stat the stream. The problem is that doesn't help me to stat file_handle since I don't know if it's a stream or not. And adding a copy of whole stream ops handler table and implementing all of these ops anew for FILE * just because of one zend_stream_read function seems a waste of code to me. Unless you show me the reason why zend_stream_read warrants this additional layer of abstraction. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115