Hi Jens (& Jennie), Thanks for your efforts. As for the syntax, I must say I do not like the idea of the curly braces. Where does that come from? Maybe there is a parsing reason, but if possible, I would avoid them. AFAIK, the DXQ extension by Suciu which also introduces "execute at" did not have that restriction. On another note, during the various phases of query parsing and analisys, we introduced ugly hacks to add a special parameter if the function application was an rpc call. That ugly stuff can now be removed. thanks again, Peter

van: Ying Zhang datum: 2006/10/24 Tue PM 06:08:51 MEST aan: Jens Teubner cc: P.Boncz@cwi.nl onderwerp: Re: XRPC syntax

On Tue, Oct 24, 2006 at 05:28:48PM +0200, Jens Teubner wrote:

...

On Tue, Oct 24, 2006 at 04:58:30PM +0200, Ying Zhang wrote:

...

What is then the right definition of the grammar rule?

XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}"

or

XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}"

(BTW, are the braces added correctly?)

It's

XRPCCall ::= "execute" "at" "{" Expr "}" "{" FunctionCall "}" ^^^^ shouldn't it be ExprSingle? Since we want only _one_ URI string here.

...

(Although it shouldn't really matter in that situation.)

...

...

I will have to think about how we can implement such a check most elegantly within Pathfinder. I'm wondering about its usefulness, though. I accept that we may want to restrict it to non-built-ins only. But is the import via a module a sensible restriction? i

I think it does make sense to filter out XRPC calls to in-query UDFs. If an in-query UDF is called with XRPC, the query just cannot be executed, since we don't want to ship the function implementation in XRPC request. So if such a query is not rejected by the compiler, it will eventually be rejected by the XRPC sender.

In my opinion, it is fine if the sender rejects such stupid queries. We will have to check different things there anyway, such as `Is there actually a remote XRPC system listening at the given URI?', `Does it support the functions that I'm trying to call there?', and so on. There's no way we can do such essential tests in the compiler. So why do some very hand-waving tests that won't be effective in practice, anyway? In my opinion, this is wasted effort (both, in terms of coding and in terms of CPU cycles).

Thus checks don't belong to the compiler, I think.

...

...

Maybe we should put even more restriction on the imported module, such as we can require that the imported module should be available in a location which is accessible via the HTTP protocol. This way, we know it for sure that both the XRPC client and the server can access the module definition file (provided there is not further authentication restriction of accessing the file), and both the client and the server access the *same* module definition file, so the argument types should be the same (right?).

You introduced so many conditionals here that I think it only strengthens my above point.

:)

I will think up other places to do such checks, if necessary.

...

Support for the new syntax, by the way, is now in CVS.

Thanks!

Jennie

...

Jens

-- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263

Be consistent. -- `perlstyle' man page