> are you saying that we should write an ANTLR parser that compiles Gremlin-XXX into Bytecode directly?
Not exactly. Currently users can send either bytecode or groovy scripts to be executed on the server. I'm saying we replace "groovy scripts evaluation" with "gremlin groovy traversal execution". In TP3, it's possible for the user to submit to the script engine something like "Thread.sleep(4000)" that will be executed inside a sandboxed vm. I'm proposing we get rid of this approach in TP4 and, as gremlin groovy script are still useful (for example, you can store a bunch of traversals to execute in a text file), we replace it with a language recognition engine that will parse what is sent and evaluate it, using a restricted grammar set. The variant for gremlin strings would still be groovy/java but the user won't be able to submit arbitrary groovy instructions. I think this is not directly related to this thread (sorry!), do you think I should start a new one to discuss this? Jorge On Tue, Apr 23, 2019 at 1:14 PM Marko Rodriguez <okramma...@gmail.com> wrote: > Whoa! — are you saying that we should write an ANTLR parser that compiles > Gremlin-XXX into Bytecode directly? > > Thus, for every Gremlin language variant, we will have an ANTLR parser. > > Marko. > > http://rredux.com <http://rredux.com/> > > > > > > On Apr 23, 2019, at 5:01 AM, Jorge Bay Gondra <jorgebaygon...@gmail.com> > wrote: > > > > Hi, > > Language recognition engines will give us a set of tokens, usually in > some > > sort of tree but the result can be thought of nested collections, for > > example: > > > > The following string "g.V().values('name')" could be parsed into > something > > like [["g"], ["V"], ["values", "name"]]. > > > > Then, we would have to create some sort of "evaluator", that translates > > these string tokens into a traversal, similar to bytecode parsing and > > execution. This evaluator can use static evaluation of the tokens (like, > do > > the tokens evaluate into something meaningful?), can be optimized with > > caching techniques (like preparing traversals) and more importantly, will > > only execute class methods that are whitelisted, i.e., users can't use it > > to execute arbitrary groovy code. > > > > Best, > > Jorge > > > > > > On Tue, Apr 23, 2019 at 12:36 PM Marko Rodriguez <okramma...@gmail.com > <mailto:okramma...@gmail.com>> > > wrote: > > > >> Hi Jorge, > >> > >>> Instead of supporting a ScriptEngine or enable providers to implement > >> one, > >>> TP4 could be a good opportunity to ditch script engines while continue > >>> supporting gremlin-groovy string literals using language recognition > >>> engines like ANTLR. > >> > >> Huh…….. Can you explain how you think of using ANTLR vs > >> ScriptEngine.submit(String) > >> > >>> Language recognition and parsing engines have several benefits over the > >>> current approach, most notably that it's safe to parse text using > >> language > >>> recognition as it results in string tokens, opposed to let users run > code > >>> in a sandboxed vm. > >> > >> How would the ANTLR-parsed text ultimately be executed? > >> > >> Thanks, > >> Marko. > >> > >> http://rredux.com <http://rredux.com/> <http://rredux.com/ < > http://rredux.com/>> > >
