On Tue, Mar 10, 2015 at 7:04 AM Rob Vesse <[email protected]> wrote:
> 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 was going to raise this exact same point, but probably not as eloquently as Rob. In the Apache Way, decisions and discussions happen in public. There is a saying that accompanies this principle: "If it didn't happen on the list, it didn't happen" > > 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 > > > > > > >
