> It's imperative that you have the ability to group multiline scripts into a single query or the reactivity of your applications will greatly suffer.
A fair point and something we might yet address as part of all this thinking. RemoteGraph is pretty new and it demonstrated a critical aspect of communications with Gremlin Server. Now we need to think about how to improve upon it. > Namely having the ability to edit/modify/add steps to an already defined traversal. I don't quite follow that point...could you please elaborate? On Wed, Apr 20, 2016 at 4:15 PM, Dylan Millikin <dylan.milli...@gmail.com> wrote: > Nice post, > > I'm going to jump straight to the end. I think that one of the problems of > doing an abstraction similar to remoteGraph is that in reality the overhead > of communicating with the server is too big to make this viable. It's > imperative that you have the ability to group multiline scripts into a > single query or the reactivity of your applications will greatly suffer. > > The Gremlin-java base also has a few limitations that some query builders > try to fix (which can only be done if you abandon the idea of a natural > gremlin language variant in favor of a query builder). Namely having the > ability to edit/modify/add steps to an already defined traversal. Though in > time it might be nice to have these be part of the original implementation. > > I personally love the idea of gremlin language variants. I just don't think > they're production value is any good without some extended functionality > (beyond what gremlin-java currently is). > > On Wed, Apr 20, 2016 at 3:23 PM, Stephen Mallette <spmalle...@gmail.com> > wrote: > > > This thread on Gremlin Language Variants has been very interesting: > > > > https://pony-poc.apache.org/thread.html/Zcazrw7k442xcwc > > > > I think that this work goes a long way to address two issues I've been > > concerned about: > > > > 1. Greater consistency in how different languages do Gremlin > > 2. Less fragmentation in terms of libraries and how they work so that > users > > aren't confused with how to get started (though I don't think the goal > here > > is to restrict choices or slow down innovation) > > > > One of the first things we should probably do is start thinking in terms > of > > the types of libraries that are built on TinkerPop (outside of those > things > > that are Graph Systems) and those are listed here currently: > > > > http://tinkerpop.apache.org/#graph-libraries > > > > Marko mentioned to me that he saw the libraries we listed here breaking > > into three categories: > > > > 1. Gremlin Language Variants - which the other thread demonstrates quite > > nicely > > 2. Gremlin Drivers - the Gremlin Server protocol implementations - those > > things that send traversals to Gremlin Server and get back results. > > 3. OGM and others - I say "others" because there might be plugins and > other > > similar odds and ends > > > > I like Marko's category system here and I think that having these kinds > of > > categories will help folks organize their libraries to fit into one of > > these spaces and make it easier for users to know what they need to get > in > > order to start doing TinkerPop in their language. > > > > Anyway, the category thing is just setting the stage for this big > > bombshell. I think TinkerPop should consider maintaining the Gremlin > > Language Variants. > > > > Heresy! right? > > > > Well, I think it's the best way to achieve consistency across languages. > > Under this model, TinkerPop provides the base language variant and people > > can choose to extend upon it, but the base stays tied to our archetype of > > Java and we end up with a much more clear story for virtually any > > programming language. > > > > So how do we do this? Slowly and deliberately. We should look to only > > include language variants where we: > > > > + have good automation in place (like what Marko did for Python), > > + some competence on the committer list in that language > > + a nice testing framework that operates in our standard build/release > > process. > > > > That's setting a high bar, but if we don't keep it high, I think we will > be > > left unable to properly support and maintain what we hang out there. > > > > I'd also like to express that we should not be looking to maintain > language > > drivers. I think that should remain a third-party community effort just > > like Graph Systems. In other words, we remain a repository for reference > > implementations for everything else. Why? Because, as it sits right now, > > just based on the level of effort for what Marko did with Python, > > maintaining a "base" Gremlin Language Variants shouldn't be hard. We > won't > > be building tons of add-on capabilities to the base variants - they will > > pretty much just stay on par with the java archetype. Drivers on the > other > > hand have lots of implementation details, with many different > technologies > > that could be used, etc. They have similar complexity to Graph System > > implementations in many ways. I also think that the drivers can afford to > > have different APIs and approaches without being detrimental to the > > community. > > > > If gremlin-js-driver wants to do: > > > > client.submit("g.V()") > > > > and gremlin-python-driver wants to do: > > > > client.send("g.V()") > > > > that's not a big deal. > > > > The last point that I'll make is that I think Gremlin Language Variants, > > that don't operate on the JVM (e.g. Jython) and use Gremlin Server, > should > > have some abstraction that is similar to RemoteGraph. RemoteGraph > exposes > > a DriverConnection interface that is currently implemented by > > gremlin-driver. The DriverConnection is responsible for sending a > > traversal to the server and returning results. It would be nice if the > > language variants had a similar interface that the various community > > drivers could implement. In that way, the user never has to do any form > of: > > > > client.submit(someGremlinString) > > > > in any language. We really need to try to make that pattern go away > across > > the TinkerPop community. > > > > So - that's was a long email. Looking forward to hearing some discussion > on > > this. > > > > Stephen > > >
