Subject | Re: [Firebird-Architect] Re: [Firebird-devel] gds__cancel_operation |
---|---|
Author | Jim Starkey |
Post date | 2004-05-06T22:57:26Z |
Roman Rokytskyy wrote:
Y-valve would dutifully pass the call the "cancelOperation" method for
the remote provider, if it had one. Since it doesn't, the call goes to
Subsystem::cancelOperation which claims, with some justification, that
the entrypoint is not defined.
It would be trivial to pass the call into the remote interface but next
to impossible to implement on the wire, since the connection is busy
doing something else. To make it work, the remote interface would need
to set up an auxiliary connection, as it does for events, long before it
started it started the request it now wants to cancel.
But xdr is boring. If I were going to take on the wire protocol, I'd
dump the clunky xdr stuff in favor of something far, far simpler. But
backwards compatible, of course.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>>> 1. Define and export isc_cancel_operation as an envelope aroundIf a client tried isc_cancel_operation on a remote connection, the
>>> gds__cancel_operation leaving functionality unchanged.
>>>
>>>
>>Rename gds__cancel_operation isc_cancel_operation and export that.
>>
>>
>
>And wire protocol docs please :)
>
Y-valve would dutifully pass the call the "cancelOperation" method for
the remote provider, if it had one. Since it doesn't, the call goes to
Subsystem::cancelOperation which claims, with some justification, that
the entrypoint is not defined.
It would be trivial to pass the call into the remote interface but next
to impossible to implement on the wire, since the connection is busy
doing something else. To make it work, the remote interface would need
to set up an auxiliary connection, as it does for events, long before it
started it started the request it now wants to cancel.
But xdr is boring. If I were going to take on the wire protocol, I'd
dump the clunky xdr stuff in favor of something far, far simpler. But
backwards compatible, of course.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376