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

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". We should try to stress the uniformity of how to register a stream protocol in PEAR package. We may not need a separate package, though, simple best practices or recommendations might be enough -- a package wouldn't be big anyway. (see http://code.google.com/p/php-stream-iterate/source/browse/trunk/php-stream-iterate/Stream/Iterate.php#199) > On Thu, 2008-01-05 at 19:23 +0000, Philippe Jausions wrote: > >> Should stream registration handling be spun into a separate package, >> PHP_Stream or PHP_StreamRegistry for instance, to add convenience methods >> and exceptions? -Philippe