You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2017/04/17 17:06:26 UTC
[DISCUSS] GLV branch
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
Re: [DISCUSS] GLV branch
Posted by Stephen Mallette <sp...@gmail.com>.
I don't know how it would work, but I've been imagining something that uses
cucumber somehow. Cypher uses it for it's language agnostic testing in
their Technology Compatibility Kit:
https://github.com/opencypher/openCypher/tree/master/tck
Again, not sure how cucumber (or whatever we use) would be setup to help us
out, but there should be something central to TinkerPop that a GLV can run
some tests against to say "This GLV is good".
On Wed, May 31, 2017 at 7:20 AM, Jorge Bay Gondra <jorge.gondra@datastax.com
> wrote:
> 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 <sp...@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 <sp...@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 <ro...@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 <
> spmallette@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
> > >> >
> > >>
> > >
> > >
> >
>
Re: [DISCUSS] GLV branch
Posted by Jorge Bay Gondra <jo...@datastax.com>.
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 <sp...@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 <sp...@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 <ro...@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 <spmallette@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
> >> >
> >>
> >
> >
>
Re: [DISCUSS] GLV branch
Posted by Stephen Mallette <sp...@gmail.com>.
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 <sp...@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 <ro...@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 <sp...@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
>> >
>>
>
>
Re: [DISCUSS] GLV branch
Posted by Stephen Mallette <sp...@gmail.com>.
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 <ro...@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 <sp...@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
> >
>
Re: [DISCUSS] GLV branch
Posted by Robert Dale <ro...@gmail.com>.
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 <sp...@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
>