Re: [PEPr] Changes in proposal for Streams::Stream_Iterate

Philippe Jausions wrote: > Hi Michael, > > Michael Gauthier wrote: >> I've thought about registering a stream filter for Crypt_GPG as well. A >> PHP_Stream package might be helpful but I haven't gotten to the point >> where I'd need it yet. What are the tricky points of registering >> handlers that would be covered by such a package? >> > I think the most important would be dealing with conflicts. Because of > that, I don't think a package should ever self-register a protocol name, > but let the user always chose it instead. > For that purpose, it may be more convenient to have a similar approach > for all packages that provide some Stream implementations, or have a > separate package to deal with that. > > Throwing an exception if the user tries to register an already in-use > protocol name, would be nice -- if this is in a separate package, would > be easier to identify too, i.e PHP_Stream_AlreadyRegisteredException, > instead of a package-specific exception, i.e. > Crypt_GPG_CannotRegisterStreamException. > > A stream registration package, could also register a unique name for the > class automatically for the user, albeit, it may not be guaranteed to be > the same one from one request to the next (but that's more userland.), > or even be a pretty one: "streamiterate" or "cryptgpg". This seems impractical - how can a user use your stream wrapper in their code if the name could change suddenly? Every call to the wrapper would require some munging like: $x = new PEAR_Stream; $a = $x->getStreamWrapper('Some_Stream_Package') . '://blah/blah'; This is really, really slow compared to a static stream and introduces an unnecessary dependency. The most obvious answer is to simply recommend that all PEAR stream wrappers prepend "pear." to the stream name. This will avoid conflicts handily. Greg