[
https://issues.apache.org/jira/browse/TINKERPOP-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16666119#comment-16666119
]
stephen mallette edited comment on TINKERPOP-2070 at 10/27/18 2:57 PM:
-----------------------------------------------------------------------
i'm not sure that you're stuck on 3.2.x from the client perspective especially
if you're just sending strings. i'd give a try with 3.3.x and see what happens.
the protocol shouldn't have changed. you just may need to reconfigure
serializers and stay away from 3.3.x Gremlin syntax/features.
was (Author: spmallette):
i'm not sure that you're stuck on 3.2.x from the client perspective especially
if you're just sending strings. i'd give a try with 3.3.x and see what happens.
> gremlin-javascript: Introduce Connection representation
> -------------------------------------------------------
>
> Key: TINKERPOP-2070
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2070
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
> Affects Versions: 3.3.4
> Reporter: Jorge Bay
> Assignee: Jorge Bay
> Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>
> Currently on gremlin-javascript, {{DriverRemoteConnection}} represents a
> single connection to the server and a {{RemoteConnection}} implementation.
> Like Python and .NET, we need to make the {{DriverRemoteConnection}} use the
> {{Client}} instead of interacting with the websocket directly.
> The dependency tree between classes should be like the following
> {code:java}
> DriverRemoteConnection
> |_ Client
> |_ Connection
> {code}
> These changes don't involve a breaking change, its more of an implementation
> issue. As {{DriverRemoteConnection}} is part of the public API the current
> implementation is a limitation.
> This blocks or at least forces awful workarounds for improvements like
> TINKERPOP-2064.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
