[Monetdb-developers] XRPC Syntax

Ying Zhang Y.Zhang at cwi.nl
Sun Oct 29 01:42:32 CEST 2006


On Sun, Oct 29, 2006 at 01:10:01AM +0200, Peter Boncz wrote:
> Dear all,
> 
> I know you don't probably want to see any more emails on this, but I will re-
> visit the proposed XRPC syntax once more.
> 
> The following proposals have been made:
> (a) "execute at" SimpleExrp FunctionCall (in the paper)
> (b) "execute at" "{" SimpleExpr "}" "{" FunctionCall "}" (currently implemented)
> (c) "execute at" "{" SimpleExpr "}" FunctionCall  (lighter variant)
> (d) "execute at" SimpleExpr "xquery" FunctionCall (XQueryD.1)
> (e) "execute at" SimpleExpr "function" FunctionCall (XQueryD.2)
> 
> I will first try to summarize the positions on these proposals:
> - Jens: stresses the point that lexical analysis should be easy. Secondary, he
> values a connection with XQueryD, with preference for full query support (not
> only module function calls). Jens supports (b), (c) and (d).
> - Jennie: seems not to care about the exact syntax. Tis may be a ery wise position.

Sorry Peter, but I'd like to make a small correction on this.

My standpoint is: I definitly prefer the syntax of option (a).  When it
is announced that option (a) cannot be implemented and using addictional
braces is an alternative, I don't realy dislike this alternative.  But I
do think it is a pitty that my favorite syntax cannot be implemented.

If option (a) is impossible, I don't care which alternative will be
chosen, because, to me, each alternative has its advantages and
disadvantages.

Tomorrow I will read the rest of your mail.

Jennie

> - Torsten: prefers parentheses notation, to denote a lexical scope with special
> semantics (similar to element and attribute). Supports (b) and (c).
> - Peter: is rapidly progressing to a point not to care, but under interrogation
> will still confess to a preference for (a).
> 
> Is this an interrogation??
> 
> Yes, yes, I will confess:
> 
> As XQueryD is "dead" in the sense that it is not even in Galax where it was
> proposed, I do not feel inclined to adapt all of the syntax necessarily (we do
> adopt "execute at" in any case, so they can be happy with that). The XQueryD
> proposal requires quite a bit of analysis and transformation to correctly parse
> a query with some variables appearing without being defined, in the free-form
> xqueries they support. This is not required when viewing an RPC as a remote
> *function* call, such that the XQuery language support for function signatures
> can be leveraged to make parameters explicit. Then, for the user the simplest
> syntax  for RPC is (a), at least in the sense that it is the shortest.
> 
> Suppose we *do* view XRPC as an extension of XQueryD (I actually don't), or
> really a special case within it, as Jens says. Because free-format xqueries
> need extra implementation effort (parameter extraction) and a protocol
> extension (to send the query definition), and cannot benefit from pre-
> processing and a function cache (easily) we can and want to use a faster
> execution strategy for the specific (XRC) case of module function calls (i.e.
> optimized to fit into the function cache -- this saves a lot of latency, from
> 170msec to 35msec) . To aid this decision, syntax support can be given (i.e.
> using the keyword "function" instead of "xquery"). Also, with two different
> keywords, systems could support both functions and free-form, or any of the
> two. Therefore, if asked for my preference after (a), I would favor (e) over
> (d). But once again, I actually do not feel much about the need to be XQueryD
> consistent.
> 
> Now Torsten's opinion is that when it is necessary to delimit the thing being
> RPC-ed, then parentheses may be the most logical delimiters. This then goes
> counter to the XQueryD proposal, which uses "xquery". His well-formulated
> argument then made me start doubting my second-best preference (e); maybe (b)
> is after all more logical. Still, it does not make me doubt about my first
> preference, (a).
> 
> \Is explicit delimiting necessary, for an extension that does not build on
> XQueryD, and only has the ambition to call single XQuery functions remotely, in
> any case? I'd say no.
> 
> What remain are Jens' reserves about (a) being possible/attractive in the
> scanner/parser. I can come up with the below short diff. Unless previous
> versions, this one works, and abides to the spirit of the scanner that refrains
> from using input()/unput() nor REJECT.
> 
> When in operator mode, the scanner should not see a QName followed by a
> parenthesis, unless it is a builtin operator name (e.g. "x" eq ("y")), so QName-
> s were not allowed. In case of XRPC style (a), this is what happens when
> finishing the parse of the URI expression( e.g. execute at "x" fcn("y")). My
> modification addes a rule with lowest preference in the OPERATOR mode to accept
> a QName (lowest pref, so it was not recognized as a builtin operator), and then
> matches the '(' in a new more EXPRFCNCALL mode that serves just that purpose.
> 
> Peter
> 
> Index: scanner.l
> ===================================================================
> RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v
> retrieving revision 1.40
> diff -r1.40 scanner.l
> 136a137
> >          || YY_START == EXPRFCNCALL           \
> 343a345
> > /*  25 EXPRFCNCALL                     */
> 368a371
> > %x EXPRFCNCALL
> 607,608c610,611
> < "execute"{_}"at"{_}?"{"            { pushState (OPERATOR); pushState
> (DEFAULT);
> <                                      yield (execute_at_lbrace); }
> ---
> > "execute"{_}"at"{_}?               { pushState (OPERATOR); pushState
> (DEFAULT);
> >                                      yield (execute_at); }
> 776a780,787
> > {QName}                            { gotoState (EXPRFCNCALL);
> >                                      pflval.qname = extract_qname (yytext,
> 0); }
> > .                                  { yield (invalid_character); }
> > }
> >
> > <EXPRFCNCALL>{
> > {_}?"("/[^:]                       { gotoState (DEFAULT);
> >                                      yield (QName_LParen); }
> Index: parser.y
> ===================================================================
> RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/parser.y,v
> retrieving revision 1.47
> diff -r1.47 parser.y
> 353c353
> < %token execute_at_lbrace               "execute at {"
> ---
> > %token execute_at                      "execute at"
> 2766,2767c2766,2767
> < XRPCCall                  : "execute at {" Expr "}" "{" FunctionCall "}"
> <                             { $$ = wire2 (p_xrpc, @$, $2, $5); }
> ---
> > XRPCCall                  : "execute at" Expr FunctionCall
> >                             { $$ = wire2 (p_xrpc, @$, $2, $3); }
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Monetdb-developers mailing list
> Monetdb-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-developers




More information about the developers-list mailing list