Skip to Content.
Sympa Menu

freetds - Re: [freetds] idea: eliminate port/instance

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Robert Gonzalez <robert AT robert-gonzalez.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] idea: eliminate port/instance
  • Date: Sat, 4 Apr 2009 14:36:07 -0600

Personally, for what I use FreeTDS for, I would have no object to what you
want to do. Making changes to current conf files would require minimal work
at worst, so I am OK with it.

+1 from me for making the changes if it makes it easier for you to
develop/maintain and easier for users to use.

On Sat, Apr 4, 2009 at 1:29 PM, James K. Lowden <jklowden AT freetds.org>wrote:

> I propose to eliminate "port" and "instance" from freetds.conf. I'd like
> feedback on the idea.
>
> In freetds.conf, one can specify:
>
> host
> port
> instance
>
> Port and instance are mutually exclusive. People get confused; they
> specify both, and then don't know (because we don't say) that port
> overrides instance. You could think of that as a failure ... of
> documentation or of design.
>
> My first thought was to eliminate "instance", and use port as follows:
>
> 1. If port is numeric, it's a port.
> 2. If port is non-numeric, try looking up the port with getservbyname(3).
>
> 3. If getservbyname(3) fails, look up the port using the UDP instance
> protocol.
>
> We could instead print loudly to stderr when both port and instance are
> found in the same section. But that won't help when Apache is involved
> and/or standard error is closed.
>
> But overloading "port" to sometimes mean an instance name could also sow
> confusion.
>
> Simplest is to eliminate port *and* instance, and denote it this way:
>
> host = servername:port
> or
> host = servername:instance
>
> and apply the above three rules to whatever is right of the colon.
>
> That mimics URL notation and config.c::parse_server_name_for_port().
>
> I would stop supporting port & instance immediately. The release notes
> would alert users to the change. I don't want to support both because the
> whole problem is confusion stemming from needless complexity.
>
> At the same time, I would change the freetds.conf parser to emit messages
> on standard error when it finds problems in the file. (Currently
> misconfigurations and unknown options are silently ignored.) That will
> help people using, say, tsql to know their setup has a problem.
>
> Thoughts? Patches? Anyone out there with a freetds.conf that would take
> more than a few minutes to update?
>
> --jkl
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>



--

Robert Gonzalez
http://www.robert-gonzalez.com




Archive powered by MHonArc 2.6.24.

Top of Page