Leyne, Sean wrote:

>Why would a special identifier be required for XNet?
>
>XNet is intended to replace the existing local connection logic, which
>doesn't require any special string.
>
>

The short answer is that the current behavior fits the architecture very
poorly and wouldn't have withstood an architectural review had Borland
ever held one. The slightly longer answer is that it was conceived for
using in a lobotomized client library that had no provision for
gateways, embedded engine access, or any of the other nifty things we'll
be adding over time. It stupidly assumes that anything it gets it
grubby paws onto should be shoved across a shared memory interface of a
server. Like every other component of the architecture, it should make
a good faith effort to determine whether the user intended for that type
of connection to be made. Checking for a characteristic connection
string satisfies this.

We may well want to the distribute a default client library that sends
any non-qualified connect string to the XNet server. But an
installation may well decide that since XNet allows any client process
to crash the server by writing over shared memory is too dangerous for a
production environment and may want to unconfigure XNet in favor of a
TCP connection to localhost. Since the XNet protocol handler can't be
deactivated, the only sure way to keep connections from going through
the XNet path is to require the XNet protocol handler to do a sanity
check like the other protocol handlers.

>
>How would a traditional local connection string be defined in the conf
>file?
>
>

Uh, Sean, that was the example I gave.

>
>
>

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376