Re: About proposal Networking::Net_IMInfo

Andrew Heebner wrote:

There seems to be a very thin line between constructive criticism, and making the user rewrite his/her entire code to suit the 'specs' of PEAR. I feel PEAR needs to loosen it's grip on the noose that the PEAR dev's wrap around everyone's neck, and allow the user to write the code the way *they* want to write it, of course, in conformity with the PEAR coding practices. After all, it *is* the maintainer's job to update the package when needed, so I don't see the big deal behind not allowing a package in, or voting -1, just because we didn't do what you told us. In all, I feel PEAR needs to loosen up, and allow the user to decide what *they* want the end user to be able to use, not what the PEAR dev's want. Other people use PEAR too, not just PEAR devs. Just my $0.02.

Well, believe it or not you are submitting to an open source community, open source in itself implies group collaboration. There *are* aspects of your package that are rather naive. The proposed flexibility would allow others to extend your work more easily, and allow it to fully fit everyone's needs, not just yours. The feedback you are getting is from experienced developers and I'd take it more to heart. I get the impression that you are taking all of this personally when you should be taking in all the valuable feedback and using it to improve your package. PEAR holds high standards, and part of how they do that is incorporate peer review. New sets of eyes on a package brings it to its full potential and prevents code of poor quality from making its way in. I'll ask you to reconsider your remarks, as this package is liked, believe it or not. But as with all things, its your prerogative. All that said, on the flip side, if I may play devil's advocate, I do feel that PEAR can be a bit too rigid -- but there are good reasons for it. From your point of view you may see a -1 as rather insulting, which IMO, is discouraging and portrays PEAR as negative and inflexible. No one, I'm sure intends this, as its all about the code and has nothing to do with anything else. Consider that those same votes would be +1 if you took the time to incorporate the suggested changes. 1.) Hardcoding anything is a bad idea, especially the images, this is something the user should control, just tell us what the status is. Anything to do with presentation is inapproriate. And the same thing with the service URL's, these can change and should be supplied as arguments instead. You can comment on what you expect it to be via the example files, but never trust a corporation to remain absolute. 2.) What if someone wants to incorporate a modual of their own IM service, besides those that you offer. Be it a self-designed IM application or one of the lesser known ones like Jabber. The answer to this is modularization. Code is a rigid and logical thing, and its hard to argue with it, its absolute and it speaks for itself. Alright, enough rambling... Regards, Richard York -- ::::::::::::::::::::::::::::::::::::::::: The Spicy Peanut Project http://www.spicypeanut.net :::::::::::::::::::::::::::::::::::::::::