Re: PEAR::UDDI in a nutshell

Thanks for getting back.

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.

Can you clarify - Is this a SOAP call ? - from the code and the UDDI website it looks like it.. - If so, It should really be implemented using one of the SOAP libraries.. Regards Alan

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

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com