I guess I'm still not certain how this DSL would get packaged with the GLVs. One of the situations I'm trying to avoid is the one we face with custom type serialization. Providers with custom types generally need to package their serializers as a separate module which users of the GLV will then add as a dependency. This creates confusion for users as they aren't able to just use the GLV by itself. They need to grab an additional dependency from their provider as well. It isn't always clear to them that this is the case.
On Fri, Nov 14, 2025 at 10:04 AM Andrii Lomakin <[email protected]> wrote: > Hi Ken, > > To clarify, the functionality you mentioned regarding remote Traversal > from a GLV is already fully supported by TinkerPop. > > While there are some current issues with the DSL processor, they are > implementation details that we intend to resolve through the > contribution of our version of an annotation processor, which will not > require any changes to the TinkerPop documentation. > > For a concrete example of our implementation of DSL, please see the > following: > > https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalDSL.java > ( > https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalDSL.java > ) > > Andrii Lomakin, > YouTrackDB development lead. > > On Fri, Nov 14, 2025 at 6:59 PM Andrii Lomakin <[email protected]> > wrote: > > > > Hi Ken, > > > > The scenario you described regarding remote Traversal from a GLV is > > automatically handled. > > > > The GLV would provide code similar to the existing implementation we > > already have, which can be found here: > > > https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalSourceDSL.java#L95 > > > > Andrii Lomakin, > > YouTrackDB development lead. > > > > On Fri, Nov 14, 2025 at 6:40 PM Ken Hu <[email protected]> wrote: > > > > > > What does this mean if someone tries to send a remote Traversal from a > GLV? > > > I'm guessing that is what makes "1. Providing DSL that does the same > call" > > > necessary. I think that scripts and traversals need to have the same > > > capabilities "out of the box" when using the GLVs. So while I think > this is > > > a good idea, I would also like to see a proposal on what can be done > for > > > remote Traversals. > > > > > > On Thu, Nov 6, 2025 at 9:47 AM Andrea Child > > > <[email protected]> wrote: > > > > > > > Hi Andrii, > > > > > > > > I like your idea as it would improve readability of traversals to be > able > > > > to reference the service directly in the grammar instead of via the > call > > > > step. Looking forward to the contribution! > > > > > > > > Andrea > > > > > > > > From: Andrii Lomakin <[email protected]> > > > > Date: Wednesday, November 5, 2025 at 8:15 AM > > > > To: [email protected] <[email protected]> > > > > Subject: Proposal: Intorduction of equalence between > call(serviceName, > > > > args:List) and method call in scripts > > > > > > > > Good day, colleagues. > > > > > > > > I would like to propose an approach to enhancing the extensibility > of the > > > > Gremlin script, which, although it does not solve all problems, will > make > > > > many Gremlin extensions feel native. > > > > The Idea, as you may have already guessed from the title, is simple: > if a > > > > service is registered in TinkerPop to treat it as a method call with > > > > parameters, such as args: List<Object> as an argument. > > > > > > > > So call like: g.schemClass("User") will be translated to > > > > g.call("schemaClass", "args" : ["User]) > > > > > > > > In such a case, providers will extend Gremlin twofold: > > > > 1. Providing DSL that does the same call. > > > > 2. Registering related service. > > > > > > > > If you agree with this proposal, I would be glad to contribute it, > as I > > > > mentioned, it does not solve all issues, such as the usage of custom > > > > predicates, but I am under the impression that it can be extended to > that > > > > case too in the future. > > > > >
