RequestOptions is specific to the driver implementation, but the class will allow you to add provider specific parameters as allowed by the Gremlin Server protocol itself. That's more than what was previously allowed by the way. If you had provider specific protocol level parameters the user would have to construct their own RequestMessage from scratch and submit that which is the lowest level at which you can communicate with the server - almost none of the protocol is hidden when you do that.
On Wed, Aug 8, 2018 at 3:11 PM Ted Wilmes <[email protected]> wrote: > That sounds like a good approach. At this point, would you envision those > being TP specific options or perhaps include include hooks to support > arbitrary provider options? > > --Ted > > On Wed, Aug 8, 2018 at 1:00 PM Stephen Mallette <[email protected]> > wrote: > > > Allow the setting of the scriptEvaluationTimeout per request has been an > > issue for a long time: > > > > https://issues.apache.org/jira/browse/TINKERPOP-1342 > > > > I've hesitated a number of times in implementing this as it seemed to > mean > > just more overloads around submit() and I didn't really want that. I > think > > i'm going to create a new class to hold all the possible parameters > called > > RequestOptions so that we basically just end up with: > > > > submit(gremlin) > > submit(gremlin, RequestOptions) > > submit(RequestMessage) > > > > That's really rough and obviously all the async variants would be there > as > > well in that pattern, but anyone who follows the driver development > should > > follow where I'm going with that. With those signatures we would then > > deprecate the other ones. I see all this change as part of 3.4.0. > > > > Please let me know if there are any concerns with this approach. Thanks! > > >
