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