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 >> >>