I'd be interested in joining such a discussion.
On 2025/11/20 19:39:58 Ken Hu wrote: > In TinkerPop 4.x, we're going to have more options since the server is > likely to host more endpoints (e.g. status). This opens up new > possibilities with how the GLVs can interact with the server and in > particular with different providers/vendors. I think we should have an open > discussion on these topics that you have brought up on the dev list > recently. Maybe we can schedule an open meeting for the first week of Dec > (to avoid the Thanksgiving holiday)? > > If anyone is interested in discussing some of these items then please reply > to this thread. We can decide on a time that works for everyone in several > days after anyone that is interested gets a chance to say so. > > On Thu, Nov 20, 2025 at 9:05 AM Andrii Lomakin > <[email protected]> wrote: > > > Good day. > > Let me provide one more argument. > > > > Not so long I read the book 'differentiate or die' that is important point > > for vendors as with tool that promotes unification by default they can't > > differentiate themselves so efficiently and prefer tools that promotes > > differentiation. > > > > I think that is valuable point. > > > > On Thu, 20 Nov 2025, 14:53 Andrii Lomakin, <[email protected]> > > wrote: > > > > > Good day. > > > I understand that it contradicts current 4.x goal. > > > > > > To decide I propose to check how many vendors can practically work > > without > > > their dependencies added , I also propose to take into account impact of > > > each vendor on infrastructure. I have a feeling that feature rich vendors > > > can't work without their dependencies added. > > > > > > > > > As one more argument JDBC users work in this way all the time and don't > > > see any issues with this approach. > > > > > > On Wed, 19 Nov 2025, 19:49 Andrii Lomakin, <[email protected] > > > > > > wrote: > > > > > >> Good day, > > >> > > >> As Ken Hu correctly noted in a separate thread, the fact that users > > >> sometimes ignore vendor libraries is leading to confusion. > > >> > > >> I propose changing how users obtain a RemoteGraphTraversal instance. > > >> Instead of allowing direct creation of the instance, I suggest using a > > >> method similar to RemoteGraphTraversalManager.connect(url, name, > > password). > > >> This new approach would enforce registration of the provider library by > > >> throwing an exception if it is missing. > > >> > > >> I recognize that this proposal may be controversial, but I believe it is > > >> worth considering as a solution to the long-lasting issue. > > >> > > >> Looking forward to reading your opinions. > > >> YouTrackDB development lead, > > >> Andrii Lomakin. > > >> > > > > > >
