Claudio Valderrama C. wrote:

>I've read several times your letter and can't understand your problem. Is it
>purely academic or practical? In other words, if the local protocol is what
>happens after all other known protocol syntaxes have been tried, why does it
>need a special prefix? It's the last chance after the previous protocols
>failed; if it can't open the file, too it will report failure.
>
>You have said many times that before suggesting a solution, one should talk
>about the problem. I can't see the big problem here.
>
>
>

There are at least two problems. One is that there is no effective way
for a configuration to skip the xnet protocol handler. On a Unix
system, for example, the remote provider must be checked before the
engine provider if NFS mounted file systems are to be checked, but if
the remote provider included the xnet protocol handler, it will always
try to make an xnet connection, short circuiting an "embedded"
configuration, meaning that if you want to handle NFS mounted databases
remotely, you can't run an embedded engine. The other reason is that an
all inclusive protocol handling significantly complicates the process of
designing the configuration files.

Maybe it would be better if we had multiple remote providers, one for
TCP, one for XNet, etc, but this is a lot of build maintenence for not
much gain. The alternative is to make the remote protocol handlers
selective about which connection strings they take on.

The bottom line is that it once may have made sense for a client side
xnet protocol handler to assume that anything it saw belonged to it, but
certainly would have worked on the server side. Now that we have a
single library used by both client and server, we have to be more
careful about who handles what.