From: pat hayes (phayes@ai.uwf.edu)
Date: 10/29/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. Fine. We could also specify explicitly that the answer bundle which is the response to a server continuation should be returned to the process which sent the continuation; this then covers the 'handing-over' of a process handle to another client. > >> 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 ..."). Yes, better. > >> 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 Certainly it seems perverse to include a must-not-bind variable in an answer template; but I can imagine some crafty cases where the form of the answer template was decided on other grounds, perhaps as a result of some software deciding to use a certain 'form', for opaque reasons of its own, which might then contain variables which were incidental to the query. (For example: suppose the client is trying to put together information from several servers by sending partial answers from one on to another as queries...) It might be best to be as unrestricting as possible in the spec, in order to allow for such cases (?) (Or maybe Im just being too damn imaginative. Your call.) >, 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. ... Indeed. Here's a related issue that troubles me slightly. We are assuming that variables are clearly distinguishable in patterns, but in any particular concrete syntax there will be some 'form' for variables (eg strings starting with '?', say). Do we want to allow an answer template to contain strings which look like variables but are not in fact variables? Whatever we decide variables really are, I bet some user will want to allow templates which have things like that in them which are not variables. Maybe we should allow for an escape syntax which allows such inclusions. For example, we could specify that any string of the form ??<non-?-char>* in an answer template stands for the string beginning with a single '?' (and therefore looks like a variable) but in fact is not a variable. > >> 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? SOme folk felt that it was important that we be clear on this point, in order to avoid the possible interpretation to the contrary, which at least one reader had formed from our draft spec, with its talk of continuations. He was under the impression that the spec would require a server to store all the state necessary to re-start any cancelled session if it were ever re-started in the future by any client, even years later. Seems to me that there is no harm in being explicit about this if it can avoid a potential misinterpretation. Pat > >Richard -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes s.pam@ai.uwf.edu for spam
This archive was generated by hypermail 2.1.4 : 10/29/02 EST