PEAR::UDDI in a nutshell

Hello list, although still on vacation, I managed to get into an internet cafe so I can say something about the lengthy discussion that aroused concerning the UDDI package the last couple of days. I'll be fully "back home" in a few days, so my apologies if it again takes some time until I resurface. Also, first of all, I'd like to state that I would not have released UDDI if I hadn't been completely sure that conditions in the two conditional +1s have all been met. I had a clean consiousness when I released the package, so apologies if I hurt some feelings here. I'd of course like to address all remaining issues and comments to everyone's satisfaction. In order to do so, I thought it might be best to address all relevant postings in one long posting. If someone thinks his (or her) posting has been neglected, please speak up, I might have overlooked something. And sorry if some information might be redundant - I am fighting through the postings using a FIFO algorithm :) Here we go ... nicos@php.net wrote @ Tue, 19 Aug 2003 22:21:45 +0200 > How come UDDI is a released package and that I can't find ANYTHING in > CVS about it ? from the manual ( http://pear.php.net/manual/en/developers.contributing.howto.php ): ---SNIP--- PHP CVS account If you want to administrate your code via CVS , you can also apply for a CVS account to have access to the pear CVS module on cvs.php.net. This makes it easier for other users to contribute to your code. If you already have a CVS repository somewhere else (e.g. on SourceForge), or if you don't want to maintain your code via CVS, you don't need the PHP CVS account. ---SNIP--- If maintaining PEAR packages in CVS becomes a must, I've got absolutely no problem with that, but then please write it in the manual. > Btw its shitty code, did it get really approved? I am always looking forward to productive criticism. Stephan (Schmidt) wrote @ Tue, 19 Aug 2003 22:36:13 +0200 > I aksed Christian to implement PEAR Error Management before releasing it :-( ... which I did, but I missed the one use of "warn". Thanks for the hint, this of course will be fixed in the next release. But apart from that, I used PEAR error management (if you don't think so, please mail me with details!) Stephan also wrote @ Tue, 19 Aug 2003 22:15:27 +0200 > Either I'm totally dumb or there's a call to a function that does not > exist. I've never heard of the PHP function 'warn()'. now that you say it ... that was code I have taken directly from the phpUDDI project. I didn't notice this non-existing function, as well. But, see above, this will be fixed when it will be replaced by PEAR::raiseError(). nicos@php.net wrote @ Tue, 19 Aug 2003 22:26:11 +0200 > Well hey! I must have to be in CVS. > I'm +1 for removing this package. see above: IMO it must not be in CVS according to the manual. ok, as you might remember, PEAR error management is no must either (according to the manual then), but is common use and will hopefully soon be in the manual. Again: if cvs is a must, I'd be happy to comply, but if it's not, I "well hey" do not see why this should be a cause for removing the package from PEAR. Alan Knowles wrote @ Wed, 20 Aug 2003 08:33:26 +0800 > a) it installs in UDDI/UDDI.php > - it should be UDDI.php oh, my bad. But one question: once the package might consist of several classes (like, for instance, PEAR::SOAP), shouldn't all of this then go into one UDDI subdirectory? > b) coding standards - this should be if ... { } thanks for the info. I thought I could maintain the "or". But I have no problem using if clauses in the next release, if required. > On a side issue - I just looked through UDDI - see the other message, > and I would seriously suggest removing it. - It looks like a handcoded > SOAP call, that could be done in < 5 lines of code... well, as far as I can say it did save me a bit of coding in one commercial project, these "5 lines of code" must be really long, and as I think we wrote we are planning to support all of the various UDDI spec versions which will go way beyond the (IMO exaggerated) "5 lines" barrier. Bertrand Mansion wrote @ Wed, 20 Aug 2003 09:44:46 +0200 > I agree again. Looks like Lukas Smith, Stefan Neufiend and Hartmut > Holzgraefe voted +1. That's only 3 votes, it should never have been > accepted. and two conditional +1s, and as I said before I thought I'd fulfilled the conditions. Let's have a look at them later in this message. Lucas Smith (one of the conditional +1s) wrote @ Wed, 20 Aug 2003 11:38:09 +0200 > I certainly gave my +1 under the condition that the > PEAR CS is followed and the code is generally cleaned up. and I published the package firmly believing that I'd done all that. But everyone makes mistakes, so if you find something you don't like or that you think does not meet the "+1 condition", please file a bug report or directly mail me. > Anyhow I guess this is a lesson for me (maybe all) that it makes no > sense to give conditional votes. I guess the best course of action is to > refrain from giving a +1 until the package is in a state that you > actually approve of. Until then one should limit oneself to making > comments ("like I like your code but"). generally, that's a good idea. It also might have been a good idea if I'd mailed you once I have cleaned up the package if that's ok now, sorry that I didn't have this idea back then. How about this as a general "rule": if there are conditional +1s, the person who gave the conditional +1 must be provided with a new version of the package and then give his final, unconditional approval? Just an idea. And finally, here a wrap-up of the conditional +1s: Lukas wrote: > Generally I am +1 for it. However there is still a fair amount of > Pearifying ahead of you (like method names). I thought I'd done that, especially with method names. If you spot anything else (Alan has informed me via list that "if" should be used instead of "or", I'll have a look into that), please let me know :-) And Greg Beaver wrote in his (very helpful - thanks!) posting: > Also, 2 points that must be in the release for me to +1 > You need to provide a brief description of the problem that this class > (and UDDI) solves, and how the class describes it at the top of the > docs, just grab something from the top of uddi.org and use a @link tag > to reference the full description. I thought I did that, general remarks about UDDI are on top of UDDI.php, the @link tag further down. If I did it wrong, please let me know. > There's no reason for you to extend PEAR, or even reference PEAR, you > don't even use any of the features (bloat) of the class :) instead of removing the reference to the PEAR class, I though'd I'd implenent two suggestions at a time and am using PEAR error handling. ok, I hope I got all important points covered. If not, please let me know :-) Thanks to all those who kept professionalism in their postings, I am sure we can sort this out. I am looking forward to your comments and suggestions. Best, Christian