Re: Bindv6only once again
On Mon, Jun 14, 2010 at 08:45:58PM +1000, Brian May wrote:
> On 14 June 2010 16:35, Marco d'Itri <md@linux.it> wrote:
> > I believe that now we fixed ~everything which can be fixed, so this
> > leaves us with the proprietary Java implementation which apparently Sun
> > is unwilling to fix.
There's no bug, so there is nothing to fix there.
Non-proprietary packages are more prone to bikeshedding -- if you want to
introduce a workaround to a problem elsewhere, you can do that. This is
usually good -- but you can't blame Sun for refusing to pander to
regressions in outside software.
Both values of bindv6only have their upsides and downsides. In my opinion,
=0 is vastly superior for anything but a few improperly ported programs, in
Marco's opinion =1 is better -- but they are still different colours of
paint you can cover your bikeshed with. And proprietary software is harder
to repaint.
> For me, bindv6only=0 seems like an ugly hack designed to make existing
> applications work without change.
"without change"? Except, you know, the whole conversion from gethostname()
and friends to getaddrinfo()? V4-mapped addresses won't show for you if you
do nothing -- they're a part of the package for the new API.
It's not an ugly hack, it is careful design aimed to make software protocol
agnostic. Without having to deal separately with every protocol, you get
forward-compatibility to any other future protocol, be it IPv17, IPX (if
someone bothers extending it), or any other private use development --
without having to modify or even recompile any existing software.
It also lets programs to bind a socket in one go without having to
separately handle IPv4 and v6.
It is bindv6only=1 what is an ugly hack, since it tries to hide errors
that result from partially botched conversions from IPv4-only to
multiprotocolness.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: