adding back dev....

With Pieter's points in mind, Marko, ultimately does the "classic" embedded
mode to using TinkerPop go away for JVM users? I mean - it's not as though
those classes disappear. I suppose that in the end there's nothing we can
really do to prevent someone on the JVM from operating at the level Pieter
wants to operate at, right?

To me, I would think that gremlin-x/gremlin-java (or however it all shakes
out) is about exposing a body of code that provides the prescribed pattern
for developing applications with TinkerPop. So our user documentation would
cease to discuss what we've dubbed the "Structure API" and would instead
focus exclusively on the "Process API" ("structure" stuff would move to the
Provider Documentation). In many ways, I think that's a direction we've
been heading anyway. All the latest recipes have been written that way.
I've noticed SO and mailing list answers being written that way. It hasn't
been 100% consistent in terms of messaging but I guess we would look to use
this pivot point to start to do that.



On Thu, Dec 1, 2016 at 1:04 PM, pieter-gmail <pieter.mar...@gmail.com>
wrote:

> I was talking about we as users.
>
> One of the first reasons I came to graphs, Neo4j and then TinkerPop way
> back was precisely because of the direct access to Node/Vertex. The user
> treats it like any other object, not a remote connection. It is the
> embedded nature that makes life so easy. In a way it was like having a
> simplistic Hibernate as the core api. 99% of queries we write is to
> retrieve vertices. Not Maps and Lists of something. TinkerPop's own test
> suite applies this type of thinking. Querying/modifying Elements and
> asserting them. Vertex and Edge abound as first class citizens.
>
> Graph, Vertex and Edge is the primary abstraction that users deal with.
> Having the direct representation of this is very very nice.
>
> It makes user code easy and readable.  You know you are dealing with the
> "Person/Address/Dog/This/That" entity/label as opposed to just a
> decontextualized bunch of data, Maps and Lists. If Vertex/Edge/Property
> were to disappear I'd say it would be the first call of duty to write a
> baby hibernate to bring the property model back in again into userspace.
>
> Regarding jdbc, this kinda makes the point. Sqlg and Hibernate and many
> many other tools exists precisely so that users do not need to use JDBC
> with endless hardcoded strings guiding the application. Making TinkerPop
> more like JDBC is not an obvious plus point.
>
> A ReferencedElement is also no good as the problem I experience is
> latency not bandwidth.
>
> I reckon the experience and usage of TinkerPop is rather different for
> java and non java people and perhaps even java folks. Hopefully I am not
> the only one who have made such heavy happy use of the TinkerPop
> property meta model and would be sad to see it go.
>
> Cheers
> Pieter
>
>
> On 01/12/2016 17:53, Marko Rodriguez wrote:
> > Hello,
> >
> >> You say "v1.property(‘name’).value()" should never happen.
> >> This is something we use all the time. Almost all the work we do is with
> >> vertices and edges and is natural to call
> >> element.property("something").isPresent(),
> >> element.property("something").value(), element.property("something",
> >> "somethingnew”)
> >
> >
> > So “we” as “provider” or “we” as “user”?
> > * If provider, of course, internally, your TinkerPop implementation
> > and supporting code can use direct structure API calls.
> > * If user, then no, users should never talk to the structure API, only
> > the process API (i.e., traversal).
> >
> > Why so strict for “users"? A few reasons:
> >
> > 1. Think about Gremlin-Python. Users only gets back “proxy”
> > vertices/edges/etc. Thus, those users won’t be able to do what Java
> > users can. Inconsistent experience/documentation.
> > 2. Vertex/Edge/etc. methods are only useful in embedded systems as
> > remotely, even Gremlin-Java users just get proxies. Again,
> > inconsistent experience/documentation.
> > 3. We should not frame interactions with a graph system in terms of an
> > “API” as much as in terms of a “database connection.”
> > - So while MySQL JDBC returns row and column objects in a ResultSet,
> > they are just proxy containers of the data in MySQL. Mutating a
> > ResultSet doesn’t alter the MySQL data.
> >
> >> With this current train of thought will the use
> >> Graph/Vertex/Edge/Property be discouraged or disappear?
> >
> > For users, yes, save that they will get “proxy objects” like
> > ReferenceVertex/ReferenceEdge/etc. I strongly disagree with our use of
> > DetachedVertex/DetachedEdge/etc. for the reason that it exposes both
> > too much data (bandwidth) and DetachedXXX objects are intended to be
> > interacted with via the structure API — e.g.
> > vertex.property(“name”).isPresent().
> >
> >> Even as things stands now are you saying
> >> vertex.property("something").value() should be replaced with
> >> g.V(vertex).values("something”)?
> >
> > For users, yes.
> >
> > Note that there is one problem:
> >
> > Graph.addVertex() is way faster than g.addV(). Why? Graph.addVertex()
> > is a direct method call to Graph without the complication of traversal
> > compilation and Traverser encapsulation. We need to make the graph
> > traversal way of CRUD to a graph system (nearly) as fast as direct
> > structure API calls. Solutions:
> >
> > 1. A MutationStrategy that ultimately compile g.addV() to just
> > Graph.addVertex() without all the fluff of Step semantics.
> > 2. Strategy loading should be tied to step usage. In other words, why
> > would we call MatchPredicateStrategy on a traversal that is g.addV()?
> > The use of match() should trigger the loading of that strategy.
> > 3. Make strategy application faster as it currently stands. This is
> > linear improvement, but still, why not.
> >
> > Thoughts?,
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
> >>
> >> Thanks
> >> Pieter
> >>
> >>
> >> On 01/12/2016 16:43, Marko Rodriguez wrote:
> >>> Hi,
> >>>
> >>>> I think we've tried a lot of things for TinkerPop 3 and that there
> >>>> are too many options for application development as well as an
> >>>> over-exposed API, so I like this direction, though a fair bit of
> >>>> complexity lies in making it happen. Before getting to that
> >>>> complexity, I don't really think of this as a "new idea". To me the
> >>>> description of gremlin-x is really just a GLV for Java. I mean -
> >>>> consider that gremlin-python (something we classify as a GLV) is
> >>>> basically "everything a python dev needs to build applications -
> >>>> nothing more/less" and that's pretty much what we want for java in
> >>>> gremlin-x. gremlin-x would basically be "everything a java dev needs
> >>>> to build applications - nothing more/less". So I'm not seeing much
> >>>> distinction there (nor the need for naming it "gremlin-x" really -
> >>>> seems to be as simple as "gremlin-java" to be in line with other GLVs
> >>>> we will have).
> >>>
> >>> Ahhhhhhhhhhhhhhhh… Okay, then there is no such thing as gremlin-core/
> >>> or gremlin-server/. Check out my packaging and subsequent reasoning:
> >>>
> >>>    gremlin-java/
> >>>      structure/
> >>>        io/
> >>>      process/
> >>>        remote/
> >>>          client/
> >>>          server/
> >>>        language/
> >>>          graph/
> >>>        machine/
> >>>          traversal/
> >>>            steps/
> >>>            strategies/
> >>>            computer/
> >>>            distributed/ **forthcoming**
> >>>
> >>>
> >>> And now, check out gremlin-python (as it currently stands):
> >>>
> >>>    gremlin-python/
> >>>      structure/
> >>>        io/
> >>>      process/
> >>>        remote/
> >>>          client/
> >>>        language/
> >>>          graph/
> >>>
> >>>
> >>> Take home points:
> >>>
> >>> 1. Gremlin-Java has a language, machine, server, and client
> >>> implementation.
> >>> 2. Gremlin-Python only has a language implementation and a remote
> >>> client implementation.
> >>> 3. remote/client is RemoteConnection and remote/server is RemoteServer
> >>> (making up that interface for now).
> >>> 4. We make more explicit the distinction between traversal machine and
> >>> traversal language and now you know which variants have machine
> >>> implementations.
> >>> 5. In the future, Gremlin-Python could have a machine implementation
> >>> and then would be native for Python-based graph systems.
> >>> - Thus, easy to grow TinkerPop into other languages.
> >>>
> >>> In this way, if you are a graph system provider with a system written
> >>> in language XXX, then you come to TinkerPop and ask:
> >>>
> >>> 1. Does gremlin-XXX exist?
> >>> 2. If so, does gremlin-XXX have a machine/ implementation?
> >>> 3. If so, then implement gremlin-XXX structure API and you are now
> >>> TinkerPop-enabled.
> >>>
> >>> In this way, if you are a graph system users with an application
> >>> written in language XXX, then you come to TinkerPop and ask:
> >>>
> >>> 1. Does gremlin-XXX exist?
> >>> 2. If so, does gremlin-XXX have a language/ implementation?
> >>> 3. If so, then code in gremlin-XXX over any TinkerPop-enabled graph
> >>> system.
> >>>
> >>> Finally, this makes making gremlin-test/ more language agnostic all
> >>> the more important. If all the gremlin-XXX languages can be verified
> >>> “natively” using gremlin-test/ (not via ScriptEngine emulation), then
> >>> we are super cool.
> >>>
> >>> Finally, cause the last finally wasn’t enough, I would make it so
> >>> gremlin-driver is in gremlin-java/ and I would keep gremlin-console/
> >>> as its own thing because, while it is a Java-based REPL, it is
> >>> language agnostic given the current work by Stephen to enable any
> >>> ScriptEngine (not just Gremlin-Groovy) to be leveraged in Gremlin
> >>> Console.
> >>>
> >>> Boom.
> >>>
> >>> Marko.
> >>>
> >>>
> >>>>
> >>>> Back to the "complexity" - and I think the questions in my mind that
> >>>> follow apply with or without this gremlin-x idea (they are general
> >>>> issues that just are faced by "remote" and GLVs):
> >>>>
> >>>> + I'll come back to this in the points below, but as a big fat
> >>>> general question: how will we deal with transactions?
> >>>> + What will be the nature of Graph.io
> >>>> <http://graph.io/> <http://graph.io <http://graph.io/>>() - in one
> >>>> sense i'd like to see that as something hidden as it is the source of
> >>>> a fair bit of confusion (i.e. someone trying to load a multi GB
> >>>> graphson file) but on the other hand it's convenient for small graphs
> >>>> - that story could be made better. Maybe Graph.io
> >>>> <http://graph.io/> <http://graph.io <http://graph.io/>>()
> >>>> being a part of "Graph" is hidden and only used by the test suite to
> >>>> load data into graph providers implementations for testing purposes.
> >>>> Of course, we will need our story in order for loading data in
> >>>> different formats if that isn't available (which I guess we need to
> >>>> do anyway).
> >>>> + Can remoting Gremlin bytecode cover everything that users currently
> >>>> do in embedded/local mode? The drawback with a remote traversal is
> >>>> that it is bound to a single transaction and you therefore lose some
> >>>> efficiency with certain graphs databases as logic with three
> >>>> traversals that might span a single transaction, for example, will be
> >>>> executed less efficiently as three different transaction refreshing a
> >>>> transaction cache each time. Maybe the server protocol needs to be
> >>>> session based? Maybe, going back to the first bullet i had, the
> >>>> transaction model needs to change so that its not bound to a single
> >>>> thread by default?
> >>>> + Related to the last point, is there an easy way to blend client
> >>>> code with server code? Meaning, if i have a body of complex logic
> >>>> right now, my only option is to submit a script. I think the
> >>>> ScriptEngine stuff should really just be used for those situations
> >>>> where you need a lambda. That's a nice, simple, easy-to-explain rule,
> >>>> whereas "do it if there is complex logic" is a bit more subjective
> >>>> (and potentially troublesome). How can GLVs get complex logic on the
> >>>> "server" (let's say the logic is written in java and available to
> >>>> gremlin server) so that it could be executed as part of some bytecode
> >>>> in any GLV?
> >>>> + It would be neat to see what kind of "server" changes we could make
> >>>> to optimize for bytecode. Right now we sorta tied bytecode execution
> >>>> into the same Gremlin Server execution pipeline as ScriptEngine
> >>>> processing. I think we could probably do better on that.
> >>>>
> >>>> Not sure there are any immediate answers to any of the above, but
> >>>> it's what I've been thinking about with respect to TinkerPop 3.3.0
> >>>> lately.
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Nov 30, 2016 at 1:11 PM, pieter-gmail
> >>>> <pieter.mar...@gmail.com
> >>>> <mailto:pieter.mar...@gmail.com> <mailto:pieter.mar...@gmail.com>>
> >>>> wrote:
> >>>>
> >>>>    Ok, if Sqlg just implements its own RemoteConnection and no need
> >>>>    for an
> >>>>    additional server in the architecture then I am a lot less
> >>>>    nervous about
> >>>>    gremlin-x.
> >>>>
> >>>>    As an aside, Sqlg has its own peculiarities and optimization
> >>>>    outside the
> >>>>    standard TinkerPop interface. Most providers will have such
> >>>>    features. If
> >>>>    the graph is not exposed directly there will need to be some way
> >>>>    to call
> >>>>    custom features. No idea how now, but still.
> >>>>
> >>>>    E.g. for Sqlg the most used such feature is
> >>>>    SqlgGraph.tx().batchMode(batchModeType) but there are others.
> Index
> >>>>    management will be another. Without being able to access these
> >>>>    features
> >>>>    too many benefits of choosing a particular provider will be lost.
> >>>>
> >>>>    Cheers
> >>>>    Pieter
> >>>>
> >>>>    On 30/11/2016 19:31, Marko Rodriguez wrote:
> >>>>> 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/> <http://graph.io/> <http://graph.io
> >>>>> <http://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
> >>>>>>> <http://markorodriguez.com/> <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
> >>>>>> <mailto:gremlin-users+unsubscr...@googlegroups.com>
> >>>>    <mailto:gremlin-users%2bunsubscr...@googlegroups.com
> >>>> <mailto:2bunsubscr...@googlegroups.com>>
> >>>>>> <mailto:gremlin-users+unsubscr...@googlegroups.com
> >>>>    <mailto:gremlin-users%2bunsubscr...@googlegroups.com
> >>>> <mailto:2bunsubscr...@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
> >>>>    <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
> >>>>    <https://groups.google.com/d/optout>.
> >>>>>
> >>>>> --
> >>>>> 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
> >>>>> <mailto:gremlin-users+unsubscr...@googlegroups.com>
> >>>>    <mailto:gremlin-users%2bunsubscr...@googlegroups.com
> >>>> <mailto:2bunsubscr...@googlegroups.com>>
> >>>>> <mailto:gremlin-users+unsubscr...@googlegroups.com
> >>>>    <mailto:gremlin-users%2bunsubscr...@googlegroups.com
> >>>> <mailto:2bunsubscr...@googlegroups.com>>>.
> >>>>> To view this discussion on the web visit
> >>>>>
> >>>>    https://groups.google.com/d/msgid/gremlin-users/50D34645-
> 5AF8-4683-8C1F-E01A3C4F7815%40gmail.com
> >>>>    <https://groups.google.com/d/msgid/gremlin-users/50D34645-
> 5AF8-4683-8C1F-E01A3C4F7815%40gmail.com>
> >>>>>
> >>>>    <https://groups.google.com/d/msgid/gremlin-users/50D34645-
> 5AF8-4683-8C1F-E01A3C4F7815%40gmail.com?utm_medium=email&utm_source=footer
> >>>>    <https://groups.google.com/d/msgid/gremlin-users/50D34645-
> 5AF8-4683-8C1F-E01A3C4F7815%40gmail.com?utm_medium=email&utm_source=footer
> >>.
> >>>>> For more options, visit https://groups.google.com/d/optout
> >>>>    <https://groups.google.com/d/optout>.
> >>>>
> >>>>    --
> >>>>    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
> >>>> <mailto:gremlin-users+unsubscr...@googlegroups.com>
> >>>>    <mailto:gremlin-users%2bunsubscr...@googlegroups.com
> >>>> <mailto:2bunsubscr...@googlegroups.com>>.
> >>>>    To view this discussion on the web visit
> >>>>    https://groups.google.com/d/msgid/gremlin-users/1b1639d8-
> 4c1d-ed65-5218-8c8786b76c97%40gmail.com
> >>>>    <https://groups.google.com/d/msgid/gremlin-users/1b1639d8-
> 4c1d-ed65-5218-8c8786b76c97%40gmail.com>.
> >>>>    For more options, visit https://groups.google.com/d/optout
> >>>>    <https://groups.google.com/d/optout>.
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >>>> <mailto:gremlin-users+unsubscr...@googlegroups.com>
> >>>> <mailto:gremlin-users+unsubscr...@googlegroups.com>.
> >>>> To view this discussion on the web visit
> >>>> https://groups.google.com/d/msgid/gremlin-users/CAA-
> H4390oFKxksw1bxDSO7Ej83NBes6NaBD_EBG77wD6QC786Q%40mail.gmail.com
> >>>> <https://groups.google.com/d/msgid/gremlin-users/CAA-
> H4390oFKxksw1bxDSO7Ej83NBes6NaBD_EBG77wD6QC786Q%40mail.
> gmail.com?utm_medium=email&utm_source=footer>.
> >>>> For more options, visit https://groups.google.com/d/optout.
> >>>
> >>> --
> >>> 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
> >>> <mailto:gremlin-users+unsubscr...@googlegroups.com>
> >>> <mailto:gremlin-users+unsubscr...@googlegroups.com>.
> >>> To view this discussion on the web visit
> >>> https://groups.google.com/d/msgid/gremlin-users/FF606E7A-
> 446F-4A4D-A3A0-BC8B2EEAEAA7%40gmail.com
> >>> <https://groups.google.com/d/msgid/gremlin-users/FF606E7A-
> 446F-4A4D-A3A0-BC8B2EEAEAA7%40gmail.com?utm_medium=email&utm_source=footer
> >.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >> 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
> >> <mailto:gremlin-users+unsubscr...@googlegroups.com>.
> >> To view this discussion on the web
> >> visit https://groups.google.com/d/msgid/gremlin-users/7935b777-
> bcec-4973-7e56-1b476944f0c5%40gmail.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > 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
> > <mailto:gremlin-users+unsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/gremlin-users/315C4503-
> D935-44F7-B7C2-98D5BC22D345%40gmail.com
> > <https://groups.google.com/d/msgid/gremlin-users/315C4503-
> D935-44F7-B7C2-98D5BC22D345%40gmail.com?utm_medium=email&utm_source=footer
> >.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/bd86a1f0-a8ff-e9b6-f15e-62791fec2622%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

Reply via email to