I think Ken provides a good point to consider about external dependencies. Andrii, for further context, traditionally, we've found that users tend to expect TinkerPop to just work with any provider. They want to download a driver in their programming language and get to work writing their applications. What they have found is that in some cases it's not quite as easy as that. For example, Ken alludes to the serializers where users often learn in a very hard way that if they use JanusGraph they need to add in a customer serializer for certain operations to work. We've made it a goal for TinkerPop 4.x to not require TinkerPop drivers to have those kinds of dependencies that complicate the user experience.
I think in this case, a DSL offers as a separate dependency by a provider doesn't exactly conflict with this goal because the DSL simply enhances the experience the user has, but doesn't require it for standard TinkerPop features to work. A user could even fallback to raw call() steps without using the DSL at all and still access the same functionality. The DSL is merely a (highly useful) convenience in this case. Ken, do you think that perspective helps align this idea to the goal of trying to keep things working out-of-the-box? On Wed, Nov 19, 2025 at 12:25 PM Ken Hu <[email protected]> wrote: > That's not necessarily the case. If you think that there are users that > don't mind doing that then it is fine. I've just seen questions from users > in the past about how to make the GLV work with specific providers because > they didn't realize they needed additional dependencies and where to find > those dependencies. I'm just wondering how and if it impacts user > experience. > > On Wed, Nov 19, 2025 at 9:18 AM Andrii Lomakin > <[email protected]> wrote: > > > Is my understanding correct that you don't support this change if it > > requires additional dependencies from vendor ? > > > > On Wed, 19 Nov 2025, 17:51 Ken Hu, <[email protected]> wrote: > > > > > I don't think this proposal requires custom serializers. I was trying > to > > > say that based on my understanding of this proposal, there may be an > > issue > > > that is similar to the one we see with custom serializers. That issue > > > being, how is this custom provider DSL packaged with the GLV so that > > users > > > can gain access to those additional methods in remote traversals > without > > > needing to add an additional dependency from the provider itself? > > > > > > On Tue, Nov 18, 2025 at 10:46 PM Andrii Lomakin > > > <[email protected]> wrote: > > > > > > > Good day, Ken. > > > > > > > > Could you clarify why you think that this proposal requires custom > > > > serializers? > > > > > > > > On Tue, Nov 18, 2025 at 11:39 PM Ken Hu <[email protected]> wrote: > > > > > > > > > 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] > .INVALID> > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
