So i took a few minutes to deal with those GLV pull requests that have been hanging out there. I did things a little differently than I had described in this thread. i created TINKERPOP-1489 branch for js work and TINKERPOP-1552 for c# work. both branches extend from tp32-glv. in this way, the GLVs are not coupled together to be forced to be merged together. they can be developed at their own pace. note that tp32-glv can house changes useful to both of these GLVs (stuff like the revised testing framework).
On Mon, Apr 17, 2017 at 3:29 PM, Stephen Mallette <spmalle...@gmail.com> wrote: > 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 >> > >> > >
