Hi, > I generally recommend the exact opposite. Neo4j shines when embedded.
And thats fine. There would simply be a EmbeddedRemoteConnection which is basically just a proxy that does nothing. No need for server stuff. > Sqlg already works of databases that is designed for remote access. And yes, thats where a full fledged RemoteConnection (like GremlinServer’s) is needed for marshaling data over a network. > Wrapping that with yet another server is an unnecessary complication. Its not about GremlinServer so much as its about RemoteConnection. If Sqlg has their own RemoteConnection implementation, then it uses that. Likewise, Neo4jServer could provide its own RemoteConnection implementation and thus, no need for GremlinServer. > (Not having used it I do not know the usability or performance impact, > however being another layer it can only degrade performance and > complexity). For embedded, its an implementation that just returns the traversal as was submitted. For remote, its as it is now. You have to send the bytecode over the network and stream back results. > Further because Sqlg already works of a remote database it supports many > jvm's directly accessing the same graph. I imagine other providers could > have the same feature. This is fine with RemoteConnection. What is “not fine” (the reason for gremlin-x) is to make it so users can’t talk with the Graph object. That is a Java thing and should not be exposed to users. More specifically, that is a Gremlin traversal machine <-> graph system provider interface. Users only interact with a RemoteConnection implementation. > So gremlin-x is fine but it is not the obvious best choice for all > architectures. I was shootin’ this idea around DSEGraph people and Bob was like: “pfff…where was this idea 4 years ago. Everyone is already addicting to sending a Gremlin-Groovy script over the network and getting a ResultSet back.” > All the above is for happy java devs. Again, the purpose is the constrain Java developers too. Things like this should never happen: v1.property(‘name’).value() v1.edges(OUT).next() cluster.submit(“1+2”) graph = GraphFactory.open(...) graph.io <http://graph.io/>(gryo()).readGraph(‘data/blah.gryo’) It should be: g.V(1).values(‘name’) g.V(1).outE().next() g.inject(1,2).sum() g.withRemote(config) // hmmm… don’t know about the last one. See ya, Marko. > Cheers > Pieter > > On 30/11/2016 16:06, Marko Rodriguez wrote: >> Hello, >> >> I think TinkerPop has too many ways of doing things. For instance: >> >> 1. Users can use graph traversal or interact with vertex/edge/etc. Java >> objects directly. >> 2. Users can interact with the graph system embedded (via the Graph >> object) or remotely (via RemoteConnection). >> 3. Users can submit Gremlin string scripts or submit Gremlin bytecode >> to GremlinServer (along with other REST/etc. type capabilities possible). >> 4. Users can use GraphML, GraphSON, or Gryo for serialization. >> 5. Users can use Gremlin-Groovy, Gremlin-Java, Gremlin-Python, >> Gremlin-Scala, etc. >> 6. Users can use Titan, Neo4j, OrientDB, etc. >> >> I think we should create a module called gremlin-x/ which is the most >> simplified, concise, recommended way to use TinkerPop. In correspondence to >> the itemization above: >> >> 1. Users can only use graph traversal. All returned elements are >> ReferenceElements. >> 2. Users can only interact with the graph remotely (where remote may >> just be a localhost connection — in-memory proxy (e.g. for TinkerGraph)). >> 3. Users can only submit Gremlin bytecode to GremlinServer (thus, only >> RemoteConnection can be used). No more security issues, no more >> uninterruptible scripts, etc. >> 4. Users can only use GraphSON as its language agnostic. >> 5. Users can use any Gremlin language variant as long is generates >> Gremlin bytecode. >> 6. Users can use any graph system provider as long as it has a >> RemoteConnection exposed (where the provider can simply leverage >> GremlinServer). >> >> Finally, we should create a separate documentation called gremlin-x.asciidoc >> which is small and discusses the rationale for the constrained specification >> and references the core reference docs accordingly. For instance, no need to >> have all the step examples re-written. >> >> I believe that this will make it easier for users to say the following: >> >> “Okay, I get it. Open a RemoteConnection from a GraphTraversalSource >> (g.withRemote(...)) and spawn traversals and get back results. Thats it?! >> Easy peasy lemon squeezy.” >> >> I believe that this will make it easier for system developers to say the >> following: >> >> “We can cover 95% of use cases by simply exposing a RemoteConnection. >> Thats it?! Easy peasy lemon squeezy." >> >> In general, this model looks at TinkerPop as a “remote database system” >> where users submit “queries” and get back “results.” That is it. Nothing >> Java-specific, nothing with executing arbitrary scripts remotely, nothing >> with REST, nothing with embedded (at least from a look-and-feel >> perspective), etc. >> >> Thoughts?, >> Marko. >> >> http://markorodriguez.com >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Gremlin-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to gremlin-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/gremlin-users/6f8790d7-9fa8-99c8-b553-1793c42f9c04%40gmail.com. > For more options, visit https://groups.google.com/d/optout.
