Jim Starkey wrote:

> The question of implementation is secondary. The primary question is
> how the API should work to best support the functionality required. That
> said, I don't see any problem in either implementation. The packet is
> recognized as a callback and processed immediately. There is no reason
> to route it back to the code that initiated the exchange.
>

Do you talk about server or client side? On client - yes, possible, but
on server we should anyway pass it to plugin, which initiated exchange.

>
> The callback doesn't wait on anything -- it's just a function. When the
> callback packet arrives, it get called. It's really that simple. Don't
> try to make it complicated.
>

Once again - on server or client?
On server callback sends a packet to the client and waits for an answer
from it.

>
> The callback mechanism works because it allows an server initiated
> conversation between the server and the client as part of the
> attach/create call.

Do you suppose to open additional port for it? I always wanted to use
existing connection. An in that case all incoming packets are gathered
by main packets processing cycle, and there is no direct conversation
possible between server and client.

> Passing back a funny status and a partially
> functional attach handle that needs additional call to operate strikes
> me as a kludge across the board. It totally breaks fb_authenticate_user
> and complicates the client side.
>

I really don't see, how does it affect client side. Attach handle, which
is not a database handle, but authentication object handle, is used only
by remote subsystem, which knows how to talk to client. It absolutely
doesn't affect the client side.

> The callback mechanism is simple, elegant, and general. It meshes well
> with the existing API (extended to pass callback addresses and
> arguments). And it allows attach_database, create_database, and
> authenticate_user to operate as single calls without the need to drop
> into multi-phase operation. It's really the right way to handle the
> problem.
>

Well, I've already agreed that with Vulcan's remote architecture
callback is possible. But this solution limits us in a choice of what we
can do in remote and what can't.

>
> I think we need to decide whether op_trusted_auth is something we want,
> first. I don't think it is.
>

I've started with it because was asked by Paul Beach. I.e. it seems that
there is some commercial need in trusted authentication. And from point
of common sense this is useful thing, I see nothing bad in it, only
good. It makes clients life simpler and secure enough. Why not?

>
>>Related question - should we protect protocol version from same numbers
>>in Interbase?
>>
>>
>>
>
> That's a good question. But from what I hear, Interbase may be already
> more or less dead, in which case the issue is moot.
>
> Anyone want to take up a collection and buy Interbase? We can use the
> money left over to have a party.
>

They still include desktop edition in Delphi family of products. This
means that client (gds32) may be present in a lot of places. I don't
know - may be protocol version was not changed. May be it's worth
looking at how new gds32.dll tries to connect to remote server, what
protocol it suggests?