Re: idea: eliminate port/instance

2009/4/4 James K. Lowden <[email protected]>:
> 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.
>

I personally don't like this way cause you can't specify a named
instance if this instance correspond to a service entry.

> 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().
>

We have to consider that we are breaking compatibility. Personally I
would suggest to use another way to specify that user is using an old
configuration and remove support after some release. Users don't like
that early configuration stop working. I never liked that much
server:port syntax but perhaps it would be better to use server:port
and server\instance like odbc (and also CVS HEAD syntax if I
remember).

> 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.
>

IMHO libraries should not output to stderr if not required explicitly to do so.

> Thoughts?  Patches?  Anyone out there with a freetds.conf that would take
> more than a few minutes to update?
>

Perhaps it would be useful to always return error if port and instance
are both specified.

freddy77
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds