>
> Like a good example of where I tend to get stuck with Gremlin is "math"
Exactly. It's mostly simple calculations using customer specific formulas.
Many calculations could be done using sack(), but .map { /* do the math */ }
is a) more flexible and b) faster as it's just a single step. String
operations are another use-case, but I only see that rarely.
For debugging purposes, some people (including me) like to add .sideEffect
{ println xyz }. If println makes no sense, like it's the case in Gremlin
Server, I still like to use lambda side-effects to mutate external
variables.
Cheers,
Daniel
On Wed, Sep 20, 2017 at 5:23 AM, Stephen Mallette <spmalle...@gmail.com>
wrote:
> It would be an option to turn off script processing, but if you're saying
> that you believe that would almost never be possible (as most production
> systems will use lambdas) then there probably isn't much point to adding
> the option. Scripts will always just be there and users will have to
> appropriately secure their systems.
>
> What patterns do you normally see in the kinds of lambdas you are writing?
> I'm wondering if there were more coarse grained patterns in lambdas that
> could be solved with a highly restrictive subset of the scripting language.
> Like a good example of where I tend to get stuck with Gremlin is "math" -
> if "math" was a general thing that needed lambdas we could probably make it
> so that the scriptengine was locked down to only include math operations.
>
> On Tue, Sep 19, 2017 at 3:17 PM, Daniel Kuppitz <m...@gremlin.guru> wrote:
>
> > >
> > > Obviously lambdas wouldn't work but that might be fine for many
> > > applications.
> >
> >
> > I would make a bet that lambdas are used in most production systems.
> When I
> > work with customers, I usually try to rewrite queries and prevent the use
> > of lambdas, but often there's simply no way to do the same thing without
> > lambdas without taking a performance hit. So if you're going to make it
> an
> > option in Gremlin Server, cool, but we shouldn't disallow lambdas
> > altogether. That's probably what you meant, but I thought it might be
> good
> > to emphasize it.
> >
> > Cheers,
> > Daniel
> >
> >
> > On Tue, Sep 19, 2017 at 11:05 AM, Stephen Mallette <spmalle...@gmail.com
> >
> > wrote:
> >
> > > I just updated the reference docs for Gremlin Server to include some
> more
> > > wording on security. I just wanted to make it more clear that Gremlin
> > > Server executes arbitrary code. I like to think people get that and
> > > understand the implications of what that means from a security
> > perspective,
> > > but..........
> > >
> > > I didn't add much more on "how to secure Gremlin Server" because I
> think
> > > what we allow for is pretty much well documented:
> > >
> > > 1. Authentication
> > > 2. Encryption
> > > 3. Script Execution Management
> > >
> > > I feel like there might be a fourth category that involves discussing
> how
> > > to physically protect Gremlin Server with firewall/network stuff, but
> I'm
> > > probably not the best person to write that (or it's simply out of scope
> > for
> > > our reference docs). If someone else has experience with that sort of
> > thing
> > > and wants to provide advice, a pull request in that area would be nice.
> > >
> > > I also wonder if we shouldn't allow Gremlin Server to be run without
> the
> > > script execution enabled. In other words, just allow the
> > > TraversalOpProcessor to execute incoming requests - make it work in a
> > > GLV-only mode basically. Obviously lambdas wouldn't work but that might
> > be
> > > fine for many applications.
> > >
> > > Any thoughts?
> > >
> >
>
