Hi Marvin,
> How can I get involved in gremlin dsl?
> I have a history with querydsl and would love to see the same behavior for
> graphs.
Here is the ticket we have so far.
https://issues.apache.org/jira/browse/TINKERPOP-786
Here are some avenues forward:
1. You do not like the approach in TINKERPOP-786
- You can provide a [DISCUSS] email related to this ticket and
pitch an approach that you feel is better.
2. You do like the approach in TINKERPOP-786
- You can comment on the ticket with extended ideas, notes,
comments, etc.
I think once we have an approach that people are happy with, we move forward
with development. Question: are you a developer?
Take care,
Marko.
http://markorodriguez.com
>
> On Sun, 31 Jan 2016 06:10 Marko Rodriguez <[email protected]> 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
>>
>>
