All It is clear from the email forwarded below (and others like it) that there is a lot of developer discussion going on behind the scenes which then turns into brain dumps to the dev@ list. Ideally as much discussion as is possible and is practical should be occurring asynchronously on the dev@ list so that it is visible to the community and the community have a chance to chime into the discussions ASAP
I have no doubt that you guys are doing good work on Tinkerpop and are clearly having in-depth developer discussions between yourselves (whether F2F, IM, Skype or some other medium) but doing this creates a barrier of entry for newcomers to the community because it gives the impression (which may/may not be warranted) that there is a private inner circle handing down decisions which is not how ASF projects should operate any only serves to get projects in trouble with the board. I am not trying to say that this is the case here since you are looking to solicit community feedback but really you should be involving the community in discussions earlier in the process and it could look that way to someone who hasn't been following the list so closely. Note that clearly we don't expect people at the ASF to never have discussions off-list because that would be impractical and unrealistic (if you sit next to someone you are going to talk to them) but you need to make sure any relevant discussions move on-list as soon as is practical which you are already doing to some extent with emails like the one forwarded but it feels like you could be doing so earlier. Rob On 09/03/2015 17:13, "Marko Rodriguez" <[email protected]> wrote: >Hi everyone, > >We have reached a wall regarding the following problems: > > 1. GraphStrategies via wrappers is not working for various vendors. > 2. TraversalEngine is specific to a Graph and thus, global to all >traversals spawned off that graph. > 3. User defined Traversal DSLs are not easily created and are not >susceptible to OLAP processing. > >As a solution, Stephen and I are bouncing around the idea of a >TraversalContext: > >Graph graph = GraphFactory.open(configuration); >GraphTraversalContext g = graph.traversal(GraphTraversal.of() > .engine(StandardTraversalEngine.instance()) > > .strategy(ReadOnlyTraversalStrategy.instance())); >g.V().out().values("name").iterate(); >g.V().values("age").iterate(); // spawn as many traversals as you want >off of g > >In essence, we want to introduce one new level of indirection from the >Graph to the Traversal. This new level is called a "TraversalContext" (no >better name yet) and it bundles the following objects: > > 1. Graph (the raw data structure) > 2. Traversal DSL (GraphTraversal, SocialTraversal, etc. etc.) > 3. TraversalEngine (Spark, Giraph, Standard, etc.) > 4. TraversalStrategies (ReadOnlyTraversalStrategy, IdTraversalStrategy, >PartitionTraversalStrategy, etc.) > > You can see a working implementation of GraphTraversalContext here: > https://gist.github.com/okram/e67252705a920cd34571 > >What problems does this solve beyond 1,2, and 3 above? > > 1. Graph.Iterators.vertexIterator() -> Graph.vertices() // back to a >"Blueprints"-style API for people wanting to work with the graph object >directly > 2. Graph.engine() goes away -- no more ThreadLocal hack. > 3. Graph.of(Traversal.class) goes away -- we will be DSL friendly with >TraversalContext. > 4. Graph.V() goes away -- its all in terms of the traversal context. >GraphTraversalContext.V() exists. > >One big pill that must be swallowed with this model -- Vertex.outE() >doesn't exist: > >Vertex v = g.V().out().next() >String name = g.V(v).out().values("name") > >Graph, Vertex, Edge, etc. no longer have Traversal methods off of them >(that is NOT DSL friendly). Therefore, everything is off of >TraversalContext. This is actually going to make DSL execution on >GraphComputer extremely easy and its going to simplify vendor strategy >code a lot -- strategies are simply cached with respects to MyGraph.class. > >Anywho… its a big deal. Functionally, things don't really change. Its >just a reorganization that is going to ultimately solve 1-3 in the >beginning which need solving before we release GA. > >If anyone has any thoughts/concerns with the desired change, please raise >them. > >Thanks, >Marko. > >http://markorodriguez.com >
