Hello,
how funny, I was discussing this issue with Stig on IRC too. I want to
implement encryption with streams too for the new encryption extension,
and we came up with something like this:
crypt(des)://blaat.txt
crypt(blowfish)://blaat.txt
and then something for zippers:
compress(zlib)://
compress(bzip)://
seems another viable idea to me...
Derick
On Wed, 17 Apr 2002, Wez Furlong wrote:
> I've just been reading through RFC 2718 (Guidelines for new URL Schemes)
> because the zlib and bzip2 wrappers have been playing on my mind recently.
>
> With the new wrappers implementation, I changed "zlib:" to "zlib://" and
> required all wrappers to have "://" after scheme part, as Sascha pointed
> out that there is an ambiguity when dealing with file names or paths
> that contain a ":" character.
>
> RFC 2718 takes great pains in highlighting that "://" should only be
> used in URLs that refer to a commonly accessible root of a hierarchy.
> So, the original "zlib:" wrapper was the correct way of specifying it,
> even if it was ambiguous in the context of fopen wrappers.
>
> The other side of things is that zlib (and now bzip2) wrappers are
> polluting the URL namespace.
>
> I'm wondering what the best way of avoiding ambiguities and namespace
> pollution might be. Here are some suggestions:
>
> 1. Don't change anything; keep things as they are.
>
> 2. For ambiguous URLs (that is, those that match scheme:schemespecific,
> rather than scheme://genericipurl), the wrapper system will treat
> scheme:foobar as a plain file named "scheme:foobar", but will treat
> <scheme:foobar> as the foobar resource using the wrapper named scheme.
> Likewise for <URL:scheme:foobar>; IIRC there is an RFC for that, but I
> couldn't find it.
>
> 3. To avoid/reduce namespace issues, move zlib and bzip wrappers into
> our php:// namespace. So the new usage would look like this:
>
> // create a bz2 version of the php tarball
> copy("php://zlib:php-4.2.tar.gz", "php://bzip2:php-4.2.tar.bz2");
>
> There would be two wrapper registration functions; one for
> top-level schemes, and another for registering wrappers within the PHP
> namespace. I actually quite like this idea; it is quite a clean solution.
>
> 4. Your suggestions...
>
> --Wez.
>
>
>
> --
> Wez Furlong
> The Brain Room Ltd.
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
-----------------------------------------------------------------------
Did I help you? Consider a gift:
http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
-----------------------------------------------------------------------
PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
-----------------------------------------------------------------------
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php