Created a jira with the idea I'm proposing.
https://issues.apache.org/jira/browse/TINKERPOP-1124
I would be willing to work on it.
On Tue, Feb 2, 2016 at 10:30 AM, Marvin Froeder <velo...@gmail.com> wrote:
> Any plans on making the return methods generic so we can specialize them?
>
> For instance, instead of
> public interface Graph {
> public Iterator<Vertex> vertices(final Object... vertexIds);
> }
> to have
> public interface Graph<V extends Vertex> {
> public Iterator<V> vertices(final Object... vertexIds);
> }
>
>
> That way, orientdb-gremlin can expose custom operations and even enforce
> types for things like Element.id() and many other creative thinking =D
>
>
> On Tue, Feb 2, 2016 at 3:52 AM, Marko Rodriguez <okramma...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I think 3.2.0 can include breaking changes if need be. However, I believe
>> all the things that I want to do will be have @Deprecated backwards
>> compatible solutions.
>>
>> Marko.
>>
>> http://markorodriguez.com
>>
>> On Feb 1, 2016, at 4:25 AM, Stephen Mallette <spmalle...@gmail.com>
>> wrote:
>>
>> > Is 3.2.0 going to be considered a "breaking" version in the sense that
>> we
>> > need to alter some APIs? or will it be possible to do 3.2.0 without
>> that?
>> > I'm in favor of a breaking version for 3.2.0 so that we can try to
>> clean up
>> > some old code especially if we have other changes driving that.
>> >
>> > On Sat, Jan 30, 2016 at 7:55 PM, Marko Rodriguez <okramma...@gmail.com>
>> > wrote:
>> >
>> >> Hello Pieter,
>> >>
>> >>> A tad selfish I know,
>> >>> but https://issues.apache.org/jira/browse/TINKERPOP-968 is what I am
>> >>> waiting for.
>> >>
>> >> The things I listed are what I care about and what I plan to work on.
>> If
>> >> you have things you care about, you can work on those. If you are
>> unsure of
>> >> a development strategy, perhaps you can get others excited about your
>> idea
>> >> with a [DISCUSS], work through pros/cons, get some buy in, etc. From
>> there,
>> >> develop the idea, test it, document it, and ultimately provide a PR to
>> get
>> >> it merged into a release line.
>> >>
>> >> http://tinkerpop.apache.org/docs/3.1.1-SNAPSHOT/dev/developer/
>> >>
>> >> SIDENOTE: A few people emailed me personally saying comments to the
>> >> effect: "Please deliver X, Y, Z feature." Note, if you want something
>> done,
>> >> do it. If you don't know how to do it, learn it. If you don't know how
>> to
>> >> learn it, ask and we can point you in the right direction. If you don't
>> >> know how to ask -- I know you are lying cause you asked me to deliver
>> X, Y,
>> >> Z. Gotcha!
>> >>
>> >> Take care,
>> >> Marko.
>> >>
>> >> http://markorodriguez.com
>> >>
>> >>>
>> >>> Cheers
>> >>> Pieter
>> >>>
>> >>> On 30/01/2016 19:09, Marko Rodriguez wrote:
>> >>>> Hello,
>> >>>>
>> >>>> With TinkerPop 3.1.1 about to be put up for VOTE, we can start to
>> turn
>> >> our attentions towards 3.1.2 and 3.2.0.
>> >>>>
>> >>>> I was thinking it would be good to have a planning session to
>> organize
>> >> JIRA and discuss order of operations. However, JIRA planning sessions
>> are a
>> >> bit boring as they are too "nitty gritty," so perhaps we can use this
>> >> thread to discuss what we (as individuals) would like to accomplish for
>> >> 3.1.2 and 3.2.0 in general. This way, we have more summaries of
>> everyone's
>> >> desires and then the specifics can be shakin' out in JIRA. As such,
>> here
>> >> are my desires:
>> >>>>
>> >>>> TinkerPop 3.1.2
>> >>>> * Test a new shuffle optimization idea in SparkGraphComputer and
>> >> if its efficient, use it.
>> >>>> * Benchmark GiraphGraphComputer at scale and optimize it where
>> >> need be.
>> >>>>
>> >>>> TinkerPop 3.2.0
>> >>>> * Gremlin DSLs -- e.g.
>> >>
>> social.people().aged(36).who().know().person("daniel").who().worksFor().company("cisco")
>> >>>> * TraversalSource API redesign. g =
>> >> graph.traversal().withComputer(…).withStrategy(…).withBulk(…). The
>> current
>> >> TraversalSourceBuilder model is horrible.
>> >>>> * OLTP/OLAP-mixed traversal -- e.g.
>> >>
>> OLAP[g.V().out()]OLTP[limit(10)]OLAP[out().values("name").order()]OLTP[sample(1)]
>> >>>> * GraphComputer API additions for intelligent data access -- e.g.
>> >> g.V().count() does not need to grab all the edges of the graph!
>> >>>> * Bulking beyond Long -- support BigInteger, Complex numbers,
>> >> Doubles, etc.
>> >>>> * Redesign TraverserRequirements -- this is a rats nest that
>> >> didn't really work out as planned and its inefficient. I think I can
>> make
>> >> this a lot more simple.
>> >>>> * ServerGraph/ServerStep/ServerStrategy -- like OLAP, but for
>> >> GremlinServer -- e.g. [GraphStep, VertexStep, ServerStep] (collaborate
>> with
>> >> GremlinServer people on this).
>> >>>> * Scope.local & Scope.global rethinking -- count(local),
>> >> dedup(local) … too many -- this is not manageable! What about
>> >> g.V().groupCount().inside(order().limit(10)) instead of
>> >> g.V().groupCount().order(local).limit(local,10).
>> >>>> * Clean up HadoopGraph configurations -- Why do we have
>> >> gremlin.spark.graphInputRDD and gremlin.hadoop.graphInputFormat. We
>> should
>> >> just have one configuration: gremlin.hadoop.graphInputClass.
>> >>>> * Publish a tutorial on the Gremlin VM and compiling other
>> >> languages to it. I would really like to have the gremlin-examples/
>> package
>> >> that Jason/Stephen were talking about.
>> >>>> * Optimize Gryo serialization and SparkGraphComputer's
>> >> GryoSerializer.
>> >>>>
>> >>>> Those are the big ticket items that I would like to get handle for
>> the
>> >> next versions of TinkerPop.
>> >>>>
>> >>>> What are your thoughts on these and what are your thoughts on what
>> you
>> >> plan to accomplish in this next push?
>> >>>>
>> >>>> Take care,
>> >>>> Marko.
>> >>>>
>> >>>> http://markorodriguez.com
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>>
>>
>
