On 19/04/02, "Andrei Zmievski" <[EMAIL PROTECTED]> wrote:
> On Fri, 19 Apr 2002, Wez Furlong wrote:
> > <?php
> > $fp = fopen("data.xml", "r");
> > stream_stack_push("xslt:style.xsl?param1=value1¶m2=value2", $fp);
> > stream_stack_push("compress.zlib", $fp);
> > stream_stack_push("crypt.des", $fp);
> > // this reads the result of applying an XSLT transform
> > // (setting parameters param1 and param2) to data.xml,
> > // and gzipping the ouput, and then encrypting it with DES
> > $data = fread($fp, 4096);
> > // now send the result somewhere over the internet.
> > ?>
>
> How about going in reverse: decrypting the data, then uncompressing it,
> and then transforming?
Stack the filters in the desired order :-)
$fp = fopen("encrypted.dat", "r");
stream_stack_push("crypt.des:decrypt", $fp);
stream_stack_push("compress.zlib:decompress", $fp);
// XSLT is in most cases not likely to be 1:1 reversible transform
// so this is probably a bad example.
stream_stack_push("xslt:style.xsl", $fp);
The filters would need to be told in which direction they should be working,
if appropriate: for example, XSLT filters can only work one-way, but
crypt or compress could be encoding/encrypting or decoding/decrypting.
> > I'm still not sure if I like using '#' as a separator for filters,
> > but can't think of another character that isn't likely to force
> > a lot of otherwise unneccessary URL encoding, or make it too cumbersome.
>
> A pipe (|)? It would be familiar to those with Unix heritage. And why
> not use colon (:) for separating filter type from filter name?
The issue is in how those names are interpreted; the main thing is to
prevent a lot of quoting because we chose the wrong delimiter.
I like the pipe, but if it's something that is otherwise a no-quoting
required character in a URL, I'd like to avoid it.
But - read on...
> By the way, I am not too keen on specifying all this stuff as a direct
> parameter to fopen(). I'd rather see something like this:
>
> <?php
> // Gnome style
> $stream = stream_create("data.xml|xslt:style.xsl|compress:zlib|crypt:des");
> $fp = fopen($stream, 'r');
> ...
>
> // Array style
> $stream = stream_create('data.xml', array("xslt:style.xsl",
> "compress:zlib", "crypt:des"));
> $fp = fopen($stream, 'r');
> ...
>
> ?>
The drawback is that the mode used to open the underlying data.xml stream
is separated from the code that instantiates it, which kind of makes it
impossible to open the stream.
We can eliminate the URL encoding/quoting issue mentioned above by
using a syntax like this:
$stream = stream_create(
"data.xml",
// this could be an array as discussed above
"xslt:style.xsl|compress:zlib|crypt:des",
"r"
);
So this would replace the fopen call entirely.
I think I like that better than overloading fopen too much;
even overloading the filename with some kind of stream/pipeline
resource is probably too much.
> > At the moment I can think of 3 basic interfaces: the standard
> > file/stream interface (that we have currently), an interface with
> > network functions (set chunk size, blocking/non-blocking, timeouts),
> > and an interface for streams that can expose their contents as a
> > memory buffer - this would be implemented by the memory streams as
> > well as by plain file streams (using mmap or equivalent).
>
> Why not blocking/non-blocking stuff for other types of streams? I can
> see some possible ones that could benefit from that.
I have undoubtably only touched the tip of the iceberg :-)
Yes, there bound to be quite a few other streams and operations
where this makes sense.
--Wez.
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
