[
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670853#comment-15670853
]
ASF GitHub Bot commented on TINKERPOP-1490:
-------------------------------------------
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/478
I agree with the `RemoteConnection` implementation being pluggable.
Therefore, the GLV should be able to use any remote connection as long as it
complies with the API. But, since pre-Python3 doesn't have any standard
implementation of a `Future`, in order to maintain this "plugablity", IMO the
GLV should be able to handle whatever type of `Future` the `RemoteConnection`
returns. This places the onus on the end user to understand what
`RemoteConnection` implementation they are using and the type of Future
returned in order to comply with the syntax required by underlying framework
implementation. This does not mean that responses need have a different API,
only that developers know how to either `yield` or `yield from` them, or use
the `concurrent.futures.as_completed` method.
The good thing is that the three possible future types (asyncio, tornado,
and concurrent) have compatible APIs, and should be able to all be handled by
the GLV in the same fashion. However, if I understand correctly (not sure that
I do) it seems to me that doing specialized handling, would require us to
commit to a certain syntax. Unfortunately, all of these problems really stem
from the Python community's unwillingness to drop the legacy Python
implementation, which the Python Software Foundation has been urging us to do
for years. If I am missing something, or there is a solution that I can't see
for some reason, please provide an example of a way that allows any pluggable
`RemoteConnection` that can be based on any of the possible Python frameworks
that maintain the syntax used for handling the resulting future by the end user.
> Provider a Future based Traversal.async(Function<Traversal,V>) terminal step
> ----------------------------------------------------------------------------
>
> Key: TINKERPOP-1490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant, process
> Affects Versions: 3.2.2
> Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is
> important for not only avoiding thread locking on a query in Gremlin, but
> also, it will allow single threaded language variants like Gremlin-JavaScript
> to use callbacks for processing query results.
> {code}
> Future<List<String>> result =
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future<List<String>> result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
> // I don't know JavaScript, but ...
> return list(names);
> })
> {code}
> ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
