Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder EXTENSIONS, 1.5, 1.6
Hello Teggy, I'd like to ask the reason why you are adding this "lighter" variant. Did I miss part of the discussion on this issue? First of all, I need to mention that, yesterday, Peter and I had (again:)) some discussion about the XRPC syntax with Jens. According to Jens, he has tried to remove the braces arround the 'Expr', since that was the decision we made during the conference call last week. But removing those braces can result in some ambiguity. So, the decision of yesterday's discussion is to just keep those braces. This should be the final decision, I think (I hope:)). I didn't have time to mail everyone about this, so I do it now. Thus your lighter variant should be in the form: execute at {URILiteral} {FunctionCall} Further, I'm wondering how useful it is to add this lighter variant explicitly. Isn't 'URILiteral' just an 'Expr'? Do you want to add this variant because the time needed for compilation can then be significantly reduced if the URI is a simple string, instead of a complex Expr? Regards, Jennie On Tue, Nov 07, 2006 at 10:10:30PM +0000, Torsten Grust wrote:
Update of /cvsroot/monetdb/pathfinder In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv15478
Modified Files: EXTENSIONS Log Message: Added support for the syntactically ''lighter'' variant of XRPC invocation. May only used if a literal URI is given:
execute at URILiteral { FunctionCall }
Index: EXTENSIONS =================================================================== RCS file: /cvsroot/monetdb/pathfinder/EXTENSIONS,v retrieving revision 1.5 retrieving revision 1.6 diff -u -d -r1.5 -r1.6 --- EXTENSIONS 31 Oct 2006 08:47:13 -0000 1.5 +++ EXTENSIONS 7 Nov 2006 22:10:28 -0000 1.6 @@ -120,7 +120,10 @@ will execute the function call given in the second pair of curly braces at the URI specified in the first pair of braces. The URI expression may be any expression that can sensibly be interpreted -as a string. +as a string. A syntactically lighter variant using a literal URI +is acceptable as well: + + execute at "<<URI>>" { <<FunctionCall>> }
XQuery RPC functionality is currently only available in Pathfinder's "milprint_summer" back-end.
------------------------------------------------------------------------- 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-pf-checkins mailing list Monetdb-pf-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins
Jennie, the lighter variant has been discussed with Peter. Please ask him. The rationale behind execute at "URI" { f() } exactly is that we can save braces in the case where the URI is specificied in the literal. No parsing ambiguities here. Making this execute at { "URI" } { f() } does not buy us anything, obviously. Think of it this way: it's just like an element constructor that uses a literal QName: no curly braces around foo needed in element foo { ... } On Nov 8, 2006, 1:31 AM, Ying Zhang wrote with possible deletions:
[...] Further, I'm wondering how useful it is to add this lighter variant explicitly. Isn't 'URILiteral' just an 'Expr'?
No, an URILiteral is a very *specific* expression -- sufficiently specific to remove any ambiguity during parsing.
Do you want to add this variant because the time needed for compilation can then be significantly reduced if the URI is a simple string, instead of a complex Expr?
Not at all -- just notational convenience. If you don't like the lighter variant, you are welcome to continue to use the equivalent execute at { "URI" } { f() } which will work also in the presence of literal URIs. Cheers, --Teggy -- | Torsten Grust | torsten.grust@gmail.com
participants (2)
-
Torsten Grust -
Ying Zhang