Helen,
I think you are confusing things again. ;-)
I'll try to address your points.

H> I wish you *would* forward it to Dmitry! Ideally, then he can sort out
H> *everyone's* confusion and update the README if he thinks there is an
H> essential deficiency there.

The problem cannot be fixed at this late stage without losing backward
compatibility, and plus I believe Dmitry would still think the
implementation is correct (which it is from a technical POV).

>>Let's try to get a common terminology for the benefit of all. Firebird
>>supports several *communication protocols*. Examples:
>>
>>1) Local (a.k.a. IPServer) c:\some\file\name.fdb
>>2) TCP/IP hostname:c:\some\file\name.fdb
>>3) NetBeui (a.k.a. Named Pipes) \\hostname\c:\some\file\name.fdb

H> 3) is inaccurate. The protocol is Named Pipes: it happens to use the
H> NetBeui transport in the various Windows distributions.

If you really want to be accurate then the protocol is always the
Firebird wire protocol and all of those are transport channels. But I
think the important part (that is: 3) is different from 1), 2) and 4))
is clear enough. Let's accept the word "protocol" for the sake of
clarity.

>>4) IPX/SPX (a.k.a. Netware) hostname@c:\some\file\name.fdb
>>
>>All of these are supported by the *client library* fbclient.dll.
>>
>>The *embedded engine* fbembed.dll embeds a client library and a
>>Firebird SS engine in one file.

H> Correct.

>>Its client library supports 2), 3) and
>>4) above for connectiong to a *stand-alone Firebird server*,

H> Correct, speaking of the client library in isolation from the embedded server.

Clarification (one hopes): a *stand-alone Firebird server* is not a
machine. It's a running fbserver.exe process located wherever you
want. A *local Firebird server* is a running fbserver.exe process
located on the same machine (and Window Station, to cater for Terminal
Server).

>>and in
>>addition supports:
>>
>>5) Embedded c:\some\file\name.fdb
>>
>>Since 1) and 5) share the same syntax, one of them has to give. Thus,
>>fbembed cannot support 1). This means that it cannot be used as a
>>client for a local (meaning on the same machine) stand-alone Firebird
>>server via the Local/IPServer protocol.

H> ...except for 4), which is a red herring...

I cannot understand what you possibly might mean. I wrote "via the
Local/IPServer protocol", which means "via 1)". Everything else,
including 4), is ouside the scope of that paragraph.

H> but the implication of your
H> reasoning adds confusion where there is none

Look who's talking! ;-)

H> since you imply that 1) and
H> 5) are two different protocols. They aren't.

According to the assumptions above they are.

H> The conflict (if it were
H> allowed, but is not) is that, while the IPServer client is operating in the
H> same IPC space as the embedded server (as it does) it can't be
H> simultaneously operating in the same IPC space as another server.

That's not how it goes. For the benefit of readers, IPC stands for
Inter-Process communication. The embedded protocol uses intra-process
communication (a.k.a. direct function calls) instead. They're two
different beasts with the same face (the same connection string
syntax). That (same syntax) is the main source of confusion.

>>It *can* be used as a client
>>for a local Firebird server via any other supported protocol.

H> Not on any of my Windows systems, other than via the network (TCP/IP or
H> Named Pipes). Named Pipes doesn't work for a local connection to a
H> stand-alone server if there is no network.

I don't know what you think you are adding to the picture by saying
"other than via the network". 2), 3) and 4) are all network protocols,
in that the traffic goes through a network stack. It might or might
not physically leave the machine (see my aside) but that's irrelevant.
So what's left "other than via the network"? Nothing.

>>Aside: when using the TCP/IP protocol with "localhost" or "127.0.0.1"
>>as hostname, it is conventional to say that we are using the "TCP/IP
>>local loopback protocol". Actully there's no such thing as a loopback
>>protocol per se: it's just that the TCP stack detects localhost and
>>127.0.0.1 and doesn't send the packets over the wire.

H> That *is* what "local loopback" means.

See above; it's entirely irrelevant.

H> It's not really an "aside" at all in the context of local
H> connections. Let's clear up this term "stand-alone server". It refers to
H> a machine that is running a database server but is NOT connected to a
H> network.

Not at all, see above.

H> On a stand-alone server, provided the TCP/IP service is enabled,
H> you can connect using TCP/IP local loopback, even if there is no NIC
H> installed on the machine. Moreover, it's what you *must* do on Windows if
H> the stand-alone server is Classic.

This is completely outside my line of reasoning and, as I said above,
irrelevant to Firebird. You can have a NIC, a loopback adapter, a
wi-fi card or whatever means you might want to build a TCP stack upon,
including pigeons. In all these cases, you're doing TCP/IP, that is
2).

H> It is true to say that the regular firebird client (i.e., one that isn't
H> embedded with a server) doesn't distinguish between localhost and a
H> networked host. Firebird isn't alone in this: http and other servers on
H> stand-alone machines depend on its being handled at a lower level, too.

OK.

H> However, it's not true that the client in fbembed.dll can't distinguish
H> between localhost (pointing to 127.0.0.1 or another local loopback address)
H> and a networked host (pointing to an IP address that is being broadcast by
H> the network). I don't know how it makes the distinction, but I know for
H> sure that it does. It distinguishes 10.12.13.1 (the dev machine's network
H> address) from 127.0.0.1 and allows the fbembed.dll client to attach to the
H> local (full) server by the former but not the latter.

If this is how it goes in your environment, then go and fix it.
localhost:some_file_name has always worked and works beautifully with
fbembed.dll on my machines and on those of a couple dozen customers.

>>I hope this clears things a bit.

H> I don't think so.

Luckily enough someone else will think otherwise. You just cannot make
everybody happy. :-)

>>If it does, it would be useful to publish it somewhere. If it doesn't,
>>then it should be corrected or things should be made clearer by themselves! :-)

H> Since this isn't the first time you have made claims about the connection
H> behaviour of fbembed.dll that I can't reproduce, at least here on a network
H> of Win2K machines, it would be a worthwhile exercise for you to get
H> together with Dmitry and, between you, to update the readme in a way that
H> dispels the potential or actual myths.

That's actually the contrary: *you* make claims and from time to time I
feel obliged to rectify. ;-)

H> In any case, the protocol conflicts should disappear in Fb 2, with Dmitry's
H> reworking of embedded to use XNET instead of IPServer.

That is not going to change anything, since XNET won't be available
for use through fbembed.dll. Unless Dmitry changes his mind and
introduces a new syntax for either embedded connections or XNET
connections.

Ciao
--
Nando Dessena
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================