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

Gregory Beaver wrote: > 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 Agreed, I think using some kind of namespace in wrapper names is good, and "pear." is a good candidate. How do we manage our own names though? Should we use the package name as a basis for it? How about packages that provide a stream but are not in the Stream category? Amazon_S3 is a good example I think. Would that become pear.servicesamazons3, pear.services.amazon.s3 ? ugly :-( pear.s3 might be causing issues down the line, who knows if some "S3" protocol name would be better suited for something else down the line. And of course the end user, would rather simply have s3:// We still need a way for a user to register the wrapper as they wish, and possibly in a consistent manner across of PEAR packages. More a convenience tool, than required though. -Philippe