Not sure if you remember all the discussions we've had (would have to dig through the mailing list to find them), but GLVs are meant to be TinkerPop maintained. There were a number of reasons for this, but basically GLVs are too important to TinkerPop's spread and adoption to be left to third-parties.
On Mon, Apr 17, 2017 at 3:12 PM, Robert Dale <robd...@gmail.com> wrote: > 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 > > >
