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

Reply via email to