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