Re: idea: eliminate port/instance

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 <[email protected]>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
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>



-- 

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