I think there's less risk and work having GLVs linked and listed on the Query Languages [Providers] pages (enhancement: specify which are developed by Apache TinkerPop or third-party/community). The risk being that the maintainer disappears and no one else has the skill/time to move it forward. Seems to have worked so far. What is the motivation to pull these in now?
Robert Dale On Mon, Apr 17, 2017 at 1:06 PM, Stephen Mallette <spmalle...@gmail.com> wrote: > I'm not sure if it's been generally noticed, but Florian Hockmann recently > produced: > > https://github.com/apache/tinkerpop/pull/600 > > which gives TinkerPop the start of a .NET based GLV. We also have a long > standing PR for the start of a JS GLV with: > > https://github.com/apache/tinkerpop/pull/450 > > In evaluating both of these PRs, I'm concerned about several things: > > 1. The method for testing GLVs is not language agnostic (our current > process is only good on the JVM) > 2. The method for serialization is in a weird place because GraphSON 2.0 > still has some limitations which need to be addressed which might lead to a > better more unified approach to how TinkerPop does serialization. > > I think that it's worth addressing these issues prior to making these two > PRs part of any release branch. Unfortunately neither concern has a quick > fix. I'm thinking about merging both of those PRs to a GLV feature branch > based on tp32 then tinkering with them from there. They are large bodies of > work and would probably be easier to evaluate and for others to contribute > to if there was a common place to work on them. From there we can think on > the two issues I listed above on the release branches and just rebase GLV > feature branch on that as needed. > > Any concerns about taking this approach? Are there other issues involved > with bringing in GLVs that should be listed? Other ways to deal with this? > > Thanks, > > Stephen >
