> Something that should help performance and might help get away from
general scripts is batching

I've thought about batching as a feature many times, but i'm not sure it
solves the use case folks typically have that causes us problems. If most
batches looked like the one in your example that would be excellent, but I
think most "complex logic" tend to contain variables and and other looping
logic that you'd like to see as part of the batch. But maybe that's a
separate problem - if i have three unrelated traversals submitting them in
batch would be nice.

> Connection could also submit scripts. I still use scripts to access Graph
for db migration and performing schema updates.

hmm - we often forget the need for schema management. a key problem with
scripts is the security angle. we have a sandbox but it is bound to groovy
and i often wonder how well it could pass a rigorous security audit. It
also has the downside that it will force you to alter how you write scripts
in that they will be type-checked on evaluation.

In an effort to keep remoting about bytecode, perhaps we leverage some of
the work already done with lambdas. Somehow, you could initialize a remote
traversal with a lambda that could have an arbitrary script? in that way
it's still sent as bytecode and not another layer to the protocol? Perhaps
that same functionality could provide a way to access "complex logic" (i.e.
stored procedures) on the server in much the way that Neo4j has its "CALL"
in Cypher:

CALL org.neo4j.examples.findDenseNodes(1000)

Maybe there could be some sort of remote "call" step that let's us do
something like that. Sorry - this email is all over the place - just
tossing things out there.




On Thu, Dec 1, 2016 at 12:32 PM, Robert Dale <robd...@gmail.com> wrote:

> As someone who has gone through the trouble to migrate all scripts to Java
> withRemote, I'll throw in my $0.02.
>
> I agree the focus should be on the Connection (being separate from Graph)
> and Traversal. I wouldn't constrain it to "RemoteConnection", just
> Connection or GraphConnection. Perhaps there's an EmbeddedConnection and a
> RemoteConnection or maybe it's URI-oriented similar to how JDBC does it. In
> either case, the behavior  of Remote and Embedded is the same which is what
> I think we're striving for.
>
> I would also like to see Transactions be Connection-oriented. With the
> right API, it could hook into JTA and be able to take advantage of various
> annotations for marking transaction boundaries.
>
> An example of Connection:
>
> Connection con = new 
> GraphConnection("gremlin:server://localhost:8182/database");
> // returns RemoteConnection
> // con = new GraphConnection("gremlin:tinkergraph:in-mem/database"); //
> returns EmbeddedConnection
> // con = new GraphConnection("gremlin:neo4j:file://tmp/neo/database");
>
> con.setAutoCommit(false)
> con.tx().begin()
> g = con.traversal()
> g.addV().next()
> con.tx().commit()
>
> Connection could also submit scripts. I still use scripts to access Graph
> for db migration and performing schema updates.
> con.submit("g.V()").all()
>
> Something that should help performance and might help get away from
> general scripts is batching. Send all traversals at once:
>
> conn.batch(
>   g.addV(),
>   g.V().count(),
>   g.V()
> ).iterate()
>
> Are there features of a lambda that couldn't be replaced by a more
> feature-rich gremlin?
> g.V().out('knows').map{it.get().value('name') + ' is the friend name'}
> g.V().out('knows').map(lambda(concat(__.it.get().value('name'), ' is the
> friend name'))
>
> Reference-only makes total sense. This works really well especially with a
> local cache or for use cases where most of the data is stored in a separate
> database. I think it would lend itself nicely to lazy loading. When you
> need values there are options for that as well
> (properties/values/valueMap).  One of the problems with 'attached' elements
> is you don't know what the implementation does. So potentially every get or
> set property call is going to the database and you don't realize it. That
> can hurt performance and have unintended consequences.
>
> For loading graphs, Connection could also load and send raw GraphSON
> conn.load(new String(Files.readAllBytes(Paths.get("gremlin.gson")))) //
> perhaps a Stream would be better
> But maybe that should be reserved for the graph side.
>
> Still there should to be some sort of schema management interface or some
> way of accessing the Graph for live updates. Think when the database is
> embedded in a remote gremlin server (ala Neo4j). Otherwise the gremlin
> server would have to be shutdown, restart with native tools, perform work,
> shutdown, restart gremlin server. Maybe it's vendor-specific on the
> Connection implementation. Maybe it's just a limitation of using embedded
> DBs going forward (Neo4j 3.x has remote capabilities). Maybe this is moot
> if the GLV is the machine.  Just something to consider.
>
>
> Robert Dale
>
> On Thu, Dec 1, 2016 at 10:53 AM, Marko Rodriguez <okramma...@gmail.com>
> 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
>> >() - 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>()
>> 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
>> <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/>>(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/>
>>
>>
>>
>>
>> --
>> 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%2bunsubscr...@googlegroups.com>
>>
>> <mailto:gremlin-users+unsubscr...@googlegroups.com
>> <gremlin-users+unsubscr...@googlegroups.com>
>>
>>    <mailto:gremlin-users%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%2bunsubscr...@googlegroups.com>
>>
>> <mailto:gremlin-users+unsubscr...@googlegroups.com
>> <gremlin-users+unsubscr...@googlegroups.com>
>>
>>    <mailto:gremlin-users%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%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
>> <gremlin-users+unsubscr...@googlegroups.com>>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/gremlin-users/CAA-H4390oFK
>> xksw1bxDSO7Ej83NBes6NaBD_EBG77wD6QC786Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/gremlin-users/CAA-H4390oF
>> Kxksw1bxDSO7Ej83NBes6NaBD_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
>> <gremlin-users+unsubscr...@googlegroups.com>>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/gremlin-users/FF606E7A-446
>> F-4A4D-A3A0-BC8B2EEAEAA7%40gmail.com
>> <https://groups.google.com/d/msgid/gremlin-users/FF606E7A-44
>> 6F-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.
>> To view this discussion on the web visit https://groups.google.co
>> m/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.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/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/CABed_4pqU_SJjEvRjuy%2BdNOxtZoApyxVH05rDiTUsxWpQaqb
> cg%40mail.gmail.com
> <https://groups.google.com/d/msgid/gremlin-users/CABed_4pqU_SJjEvRjuy%2BdNOxtZoApyxVH05rDiTUsxWpQaqbcg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

Reply via email to