From: Richard Fikes ([email protected])
Date: 10/27/02
> This message is an attempt to summarize the suggestions made at the > PI meeting concerning changes to the DQL spec. > I recommend that we make these changes to > the spec, and the obvious ancillary simplifications that they produce. I agree, with the following additional comments -- > 1. Non-fixed bundle size > > A client can return a revised bundle size bound with each > continuation. If this is omitted, the previous bundle size bound is > assumed. This suggestion prompts me to recommend that we make a minor refinement in our terminology in the client-server protocol specification. Specifically, we say in the spec that (1) a "server continuation" is included in an "answer bundle" that is passed from the server to a client, (2) a "server continuation" is either a "process handle" or "one or more termination tokens", and (3) that a client passes a "server continuation" back to the server as a way of requesting more answers from the server. We now want to add a "bundle size bound" to what a client sends to the server when requesting more answers. Also, in general, we want to allow servers to support various extensions to the core protocol described in the spec, and so I think we want our spec to be structured so that additional property-value pairs can be included in the messages that are passed between clients and servers, as supported by the particular server. Our current design is "overloading" the notion of "server continuation" in that the server includes a server continuation in what it sends the client, and then a client sends the server continuation back to the server (in order to request additional answers). But we want the client to be able to send the server more than the process handle that is the server continuation, e.g., at least a new "bundle size bound". I recommend the following change in terminology. We change the spec to say that an answer bundle consists of an answer set and either a process handle or a set of termination tokens (i.e., we don't call what's in an answer bundle a server continuation). We then say that a client sends a server continuation to a server as a way of requesting more answers and that a server continuation necessarily contains a process handle and optionally contains a bundle size bound. Servers can then specify additional optional property-values for server continuations, just as they can do for queries and for answer bundles. > 2. Number of answers. > > Optionally, a bundle can begin with a number indicating the number of > answers still to be delivered *after* the current bundle. The answer > number of any bundle containing a terminator should be zero. There is > no default value: if the answer number is omitted, then no > information is supplied about the number of answers. Let's simply make the number of answers still to be delivered after the current bundle a value of some optional property in an answer bundle (rather than saying "a bundle can begin with ..."). > 4. Answer templates. > > A query must supply an answer template, which is a character string > (?? Piece of DAML?? I prefer the more generous definition) containing > some of the variables in the query pattern. If no answer template is > explicitly provided, then the query pattern is the default answer > template (Sandro's idea). The answer template interacts with the must-bind variables list and the may-bind variables list. We need to make some design decisions about that interaction. We could say that the variables in the answer template *are* the may-bind and must-bind variables, and then that a query can optionally include a must-bind variables list indicating which of the variables in the answer template must have a binding in an answer. There would then be no need for a may-bind variables list. That would remove redundancy from the query, but would require more work by the server. ... > 6. Session ending. > > A series of transactions between client(s) and server consisting of a > query followed by answer bundles and continuations is an 'answering > session'. If such a session is interrupted or terminated by an > underlying network control layer, then it is permissible for a server > to be unable to continue the answering session even if it is sent a > continuation. In such cases the server should respond with an answer > bundle containing the terminator 'end'. I don't see how this impacts the DQL spec. That is, do we need to say anything about this in the spec? Richard
This archive was generated by hypermail 2.1.4 : 10/27/02 EST