Re: Suggestions for DQL changes made at Portland

From: pat hayes (
Date: 10/29/02

  • Next message: Mike Dean: "Joint Committee telecon today 5 November"
    >  > 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.
    IHMC					(850)434 8903   home
    40 South Alcaniz St.			(850)202 4416   office
    Pensacola              			(850)202 4440   fax
    FL 32501           				(850)291 0667    cell	   for spam

    This archive was generated by hypermail 2.1.4 : 10/29/02 EST