When a connect string is passed to the remote provider, the remote
interface calls each protocol handler in turn to analyze the connect
string and determine whether it should/can make a connection to a
corresponding server. The analyses are a generally a combination of
connect string syntax and environment. The TCP protocol handler looks
for either the intervening punctuation ":" between presumed node name
and remote connect string or whether the connect string is a file name
in a NFS mounted file system. The Apollo protocol handler checked to
see if the database file was open somewhere on the network, and if so,
connected to that node. The DECnet handler looked for "::" separating
the DECnet node name and remote connect string.

The XNet protocol handler doesn't do this, and assumes that any connect
string should be should be passed to a local server over the XNet
communication system. While I think we could retain this behavior and
still honor most configurations, I think it's a liability that should be
corrected. I'd like to add an arbitrary prefix for XNet bound connect
strings in the same vein as the suggestion for an explicit prefix for
in-process (embedded) engine access. For the prefixes, I suggest we
pick an arbitrary piece of punctuation (maybe one of |, #, !, ?, or
%). This would make an explicit XNet connect string for the file
"foo.fdb" be "xnet#foo.fdb" (or "xnet|foo.fdb", etc.). This would
generally be user transparent, handled with a variation on the following
in the client.conf file:

<database xnet#*>
filename $0
provider remote
</database>

<database *>
filename xnet#$0
</database>

So a connect string of "foo.fdb" would first be rewritten to
"xnet#foo.fdb", then passed to the remote provider. The XNet protocol
handler in the remote interface would strip off the "xnet#", expand the
remaining connect string as a filename string, then pass the expanded
string to the Winserver.

So two questions. First, does this seem like a good idea? Second,
assuming it is a good idea, what is the best choice of punctuation?

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376