[Monetdb-developers] XRPC syntax

Ying Zhang Y.Zhang at cwi.nl
Fri Oct 27 12:38:31 CEST 2006


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




More information about the developers-list mailing list