Hi, I'm not sure I understand what you mean by "The method for testing GLVs is not language agnostic"? It would be nice to have a reusable test suite to make a GLV pass through but it would involve a communication mechanism between 2 different runtimes (ie: jvm and dotnet) that could be very hard to maintain. I think that having unit and integration tests on the GLV implementation should be enough. Which functionality and the level of coverage should be defined upfront, though.
Jorge On Thu, May 18, 2017 at 7:01 PM, Stephen Mallette <spmalle...@gmail.com> wrote: > 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 > >> > > >> > > > > >
