[
https://issues.apache.org/jira/browse/TINKERPOP-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16044527#comment-16044527
]
Florian Hockmann commented on TINKERPOP-1552:
---------------------------------------------
{quote}
We could fix that issue by using Traverser<object> for TraverserReader and
TraverserAggregator references, but I wouldn't know the implications.
{quote}
I just gave that a quick try, but it doesn't work that easily with the result
aggregation. The connection needs to return a collection of {{Traverser<E>}}
but it now gets a {{Traverser<object>>}}. We could handle that but it would
probably require a dedicated {{ReceiveAsync}} that only works with
{{Traverser<E>}} objects. The current version is still able to return any
collection of objects. But that should only be necessary when the user wants to
continue sending Gremlin scripts as strings. The GLV itself only needs to
receive traversers.
Another option would be to also use the type parameters for the GraphSON
deserialization, but that seems to be a lot more complicated.
> C# Gremlin Language Variant
> ---------------------------
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
> Affects Versions: 3.2.3
> Reporter: Jorge Bay
> Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of
> the trickier bits to deal with.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
