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 <okramma...@gmail.com> 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
>> 
>> 

Reply via email to