[Monetdb-developers] XRPC syntax

p.a.boncz at chello.nl p.a.boncz at chello.nl
Fri Oct 27 12:38:42 CEST 2006


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 <Y.Zhang at cwi.nl>
> datum: 2006/10/24 Tue PM 06:08:51 MEST
> aan: Jens Teubner <jens.teubner at in.tum.de>
> cc: P.Boncz at 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
> 





More information about the developers-list mailing list