[jira] [Updated] (TINKERPOP-2249) Improve RequestOption passing

["Stephen Mallette (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stephen Mallette updated TINKERPOP-2249:
----------------------------------------
    Description: 
{{RequestOptions}} provides a way to set certain control arguments to send to the server like a per-request timeout or batch size. For bytecode traversals, these are set somewhat statically and selectively by way of {{with()}} which are then gathered by {{DriverRemoteConnection}} into a {{RequestOptions}} object and then sent to the server on the request - it's basically leading to a giant switch statement as new special options are being added.

Perhaps we should also consider a "request headers" space on the {{RequestMessage}} rather than just throwing all these options in at the "args" level.

Another idea might be to do {{with(TraversalSourceOptions)}} where {{TraversalSourceOptions}} would be a new interface that something like {{RequestOptions}} could implement. That way we could pass around {{RequestOptions}} in a consistent way:

{code}
submit("g.V()", RequestOptions.build().timeout(100).create())
g.with(RequestOptions.build().timeout(100).create()).V()
{code}

rather than:

{code}
g.with("evaluationTimeout", 100)
{code}

  was:
{{RequestOptions}} provides a way to set certain control arguments to send to the server like a per-request timeout or batch size. For bytecode traversals, these are set somewhat statically and selectively by way of {{with()}} which are then gathered by {{DriverRemoteConnection}} into a {{RequestOptions}} object and then sent to the server on the request - it's basically leading to a giant switch statement as new special options are being added.

Perhaps we should also consider a "request headers" space on the {{RequestMessage}} rather than just throwing all these options in at the "args" level.


> Improve RequestOption passing
> -----------------------------
>
>                 Key: TINKERPOP-2249
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2249
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: driver, server
>    Affects Versions: 3.4.2
>            Reporter: Stephen Mallette
>            Priority: Major
>
> {{RequestOptions}} provides a way to set certain control arguments to send to the server like a per-request timeout or batch size. For bytecode traversals, these are set somewhat statically and selectively by way of {{with()}} which are then gathered by {{DriverRemoteConnection}} into a {{RequestOptions}} object and then sent to the server on the request - it's basically leading to a giant switch statement as new special options are being added.
> Perhaps we should also consider a "request headers" space on the {{RequestMessage}} rather than just throwing all these options in at the "args" level.
> Another idea might be to do {{with(TraversalSourceOptions)}} where {{TraversalSourceOptions}} would be a new interface that something like {{RequestOptions}} could implement. That way we could pass around {{RequestOptions}} in a consistent way:
> {code}
> submit("g.V()", RequestOptions.build().timeout(100).create())
> g.with(RequestOptions.build().timeout(100).create()).V()
> {code}
> rather than:
> {code}
> g.with("evaluationTimeout", 100)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)