On 18 Dec 2003 at 15:14, Mike Taylor wrote:
> > Date: Thu, 18 Dec 2003 14:15:46 +0100
> > From: Theo van Veen <[log in to unmask]>
> > Why not the following in case the record schema is specified?
> > Client requests recordSchema A,
> > Server responds with one of the following:
> > 1. A
> > 2. Sorry I don't have A
> > 3. extraRequest Data: We have B which could be used instead of A
> (I assume you mean that the server responds with extraResponseData)
> That's fine, so long as the client has signalled its willingness to
> accept such an extraResponseData packet by sending the appropriate
> "let me know what other schemas you've got if you can't do the one I
> asked for" extraRequestData packet.
yes, that's what I meant
> (Side-issue: we've always agreed up till now that
> servers may not unilaterally include extraResponseData,
> but only in response to an extraRequestData. Though I
> would not be unwilling to revisit that rule if there
> are compelling reasons to do so.)
This is not what I meant and because of extraRequestData it is not needed anymore.
> But then we're getting dangerously close to an informally-specified,
> ad-hoc, bug-ridden implementation of half of ZeeRex. Why bother? Why
> not just find out what schemas are supported from the ZeeRex record
> and have done?
In this example asking for A makes no sence, unless the server knows more about A
than the client knows about B. For example when the server has full and brief records
with schema B and C and extraRequestData allows the server to send full records when
maximumRecords is 1 and brief records when the maximumRecords>1.