[
https://issues.apache.org/jira/browse/TINKERPOP-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634322#comment-16634322
]
ASF GitHub Bot commented on TINKERPOP-2015:
-------------------------------------------
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/928
IMO it would be better to expose the options as a property unless there's a
good reason to not allow any changes in options after the client has been
initialized. But since the underlying `ClientWebSocket` allows a change in
options at any point in time, `GremlinClient` should preferably do the same.
> Allow users to configure the WebSocket connections
> --------------------------------------------------
>
> Key: TINKERPOP-2015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2015
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
> Affects Versions: 3.3.3, 3.2.9
> Reporter: Florian Hockmann
> Assignee: Florian Hockmann
> Priority: Major
>
> Gremlin.Net currently just creates instances of the {{ClientWebSocket}} class
> with default options. That is probably appropriate for most users but it
> makes it impossible to change the config and use certain features like client
> certificates or proxy settings.
> We could simply allow users to provide a
> [{{ClientWebSocketOptions}}|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions]
> object. Since it's part of .NET Standard (and not a 3rd party library) it
> shouldn't be a problem to expose this type. This would also have the nice
> advantage that users could immediately use new options like the
> {{[RemoteCertificateValidationCallback|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions.remotecertificatevalidationcallback]}}
> that was just added in .NET Core 2.1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
