I think I'm changing my mind about making provider specific parameters allowed here without a specific use-case in mind. As i started to implement it, I realized that if you're a user and need to do something like this, you probably know what you're doing and would be constructing the RequestMessage yourself manually. I just don't feel like I'm saving a lot of steps here and I'm not helping keep things easy for users - i'm giving them something that they could hurt themselves with.
Anyway, If there are an providers/users out there who would find benefit to having this please provide your reasoning for further discussion. On Wed, Aug 8, 2018 at 3:20 PM Stephen Mallette <[email protected]> wrote: > 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! >> > >> >
