Re: (XMLRPC-27) Patch to allow protocol://user:password@host.domain.tld urls

[Jochen Wiedmann <jo...@gmail.com>]

Hi,

after waiting some days, it seems to be about time to reply to the
above subject.

First of all, though being a very experienced Perl programmer and
liking Perl: I am no fan of its TMTOWTDI mantra. I really do believe
that libraries like XML-RPC are best, if they are as small as
possible. If there is a good, generic solution for a problem, then
there is no reason to add another one, unless it adds functionality or
offers a performance gain because a short cut is possible. Everything
else is simply adding maintenance burden to the libraries developers.

In particular, I do receive the right for me to decide whether I want
a patch in or not. If someone writes a patch, that's fine. But let's
assume the following: We have a bean class with a default constructor
and lots of properties. Someone offers a patch, which adds a two args
constructor, that calls two setters immediately. Should I accept this
patch, just because it offers convenience? My answer is no. And that
is exactly what I see here: Someone wants a convenience method for
specifying credentials, although there already is a good solution for
that. (Not to mention the technical merits of the patch, which will
always assign an empty password.)

Second: Have you ever considered deriving a subclass, which does
exactly what you want? Noone prevents you doing so, in contrary, you
are explicitly called for. (Note, that the guy from the example above
could very well create another subclass with his two args
constructor.)

Third, please note that I am not the only developer. You are free to
convince others. I simply state, that I do not want to pull the patch.
If it would come to a vote, then I'd reply with -0 (in other words, I
do not want it, but I won't raise a veto.)

Jochen

--
Whenever you find yourself on the side of the
majority, it is time to pause and reflect.
(Mark Twain)