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]> > > > > > > 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. > > > > > > > > > > > >
