[Monetdb-developers] XRPC syntax

Jens Teubner jens.teubner at in.tum.de
Fri Oct 27 12:38:19 CEST 2006

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?)


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

(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).

> 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.

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


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

More information about the developers-list mailing list