On Fri, 19 Apr 2002, Wez Furlong wrote:
> The nice thing about this is that a range of encodings/decodings
> can be applied/removed based on the data that has just been read
> from the file.
>
> I think this sort of thing might be useful for things like
> templating processors:
>
> <?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?
> It is useful to be able to specify that as a single URL parameter;
> gnome concatenates things with the '#' sign - I also think that
> specifying an array would also be useful, because it could be built
> dynamically:
>
> <?php
> // Gnome style
> $fp = fopen("data.xml#xslt:style.xsl#compress.zlib#crypt.des"), "r");
> $data = fread($fp, 4096);
> // Array style
> $fp = fopen(array("data.xml", "xslt:style.xsl", "compress.zlib",
> "crypt.des"), "r");
> $data = fread($fp, 4096);
> ?>
>
> 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?
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');
...
?>
> 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.
-Andrei
"Music expresses that which can not be said
and on which it is impossible to be silent."
-Victor Hugo
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
