Thanks to everyone who was able to join the discussion. For those who couldn't attend, this discussion primarily focused on priorities and timelines for the various outstanding proposals on the devlist. I've included below some notes on the discussions:
Attendance: - Cole Greer - Yang Xia - Lev Sivashov - Andrea Child - Ken Hu - Andrii Lomakin Discussion Topics: - Match() overhaul (GQL integration) - This is a high priority for YouTrackDB and they are invested in building this capability and contributing it to TinkerPop. - TinkerPop 4 - We discussed a rough goal of having TP4 completed in ~6 months time. This will require dedicated discussions on the devlist to build consensus on final scope and timelines for the release. - Lots of work is still needed in gremlin-server for TP4, namely transactions and a new provider extensibility model to replace OpProcessors. - Structure API - Concerns were raised that usage of the structure api creates a "lock-in" for embedded users as they cannot directly migrate their application to remote graphs. - It was also raised that the structure api is currently a critical tool to enable users to write their own graph algorithms beyond what is easily expressed in gremlin, without resulting in infinite extensions to gremlin to cover every possible niche use case. - Some interest was expressed in using WASM lambdas to replace this current use-case for the structure api, which would allow users to write similar code in their native language of choice, and have it be compiled to WASM and executed remotely. This could be a tool to unify the embedded and remote use cases, as well as the structure and process APIs. - This is all a very long term vision beyond the scope of any immediate work, and will require substantially more discussions and considerations before any consensus is reached. We agreed it would be useful to meet again in the new year to continue these discussions. A rough mid-January date was suggested to give some time for ongoing proposals and implementations to progress. I will follow up with a dedicated discussion to schedule this meeting, and potentially organize a regular recurring event. Thanks, Cole On 2025/12/05 22:05:30 Cole Greer wrote: > I've created a microsoft teams meeting invite for Tuesday Dec. 9 at 16:00 > UTC. I've directly invited all folks active in this thread to the meeting. > Anyone else who is interested may join with this link: > https://teams.microsoft.com/l/meetup-join/19%3ameeting_MjExNTRiOGYtYTA3ZC00Njk3LTgzMTAtNTU5NzAzYjI5YzRj%40thread.v2/0?context=%7b%22Tid%22%3a%22f2267c2e-5a54-49f4-84fa-e4f2f4038a2e%22%2c%22Oid%22%3a%22f3bad5a5-c1a2-4172-b5ad-54f2ac72b2c8%22%7d > > Anyone is welcome to join, no account is necessary. > > Regards, > Cole > > On 2025/12/05 17:48:37 Cole Greer wrote: > > Hi Andrii, > > > > Tuesday at 08:00 PST/17:00 CET/16:00 UTC seems to work best for everyone > > involved. I'll send a meeting invite that anyone who can join shortly. > > > > Thanks, > > Cole > > > > On 2025/12/05 09:31:39 Andrii Lomakin via dev wrote: > > > Good day Cole, > > > Can we make it at Tuesday, time you proposed ? > > > > > > On Tue, Dec 2, 2025 at 10:51 PM Ken Hu <[email protected]> wrote: > > > > > > > I don't have a preference. All of those dates/times should work for me. > > > > > > > > On Tue, Dec 2, 2025 at 12:32 PM Cole Greer <[email protected]> wrote: > > > > > > > > > Hi everyone, > > > > > > > > > > Apologies for my delay in scheduling this meeting. I believe a time of > > > > > 08:00 PST/17:00 CET/16:00 UTC is best for everyone who has responded > > > > here. > > > > > I suggest scheduling the meeting this coming Friday, Monday, or > > > > > Tuesday > > > > > (Dec. 5, 8, or 9). > > > > > > > > > > Please let me know of any preferences between these days, or if an > > > > > alternative date/time is needed. I will schedule an open meeting once > > > > > we > > > > > have agreement on the date and time. > > > > > > > > > > Thanks, > > > > > Cole > > > > > > > > > > On 2025/11/25 08:01:09 Andrii Lomakin via dev wrote: > > > > > > Sorry, my bad, lost in time zones: It is 12:00 AM to 10:00 AM in PT. > > > > > > > > > > > > On Tue, Nov 25, 2025 at 8:58 AM Andrii Lomakin < > > > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > My preferred times are 09:00 to 19:00 CET (08:00 to 18:00 UTC), > > > > > > > which > > > > > is > > > > > > > 12:00 AM to 1:00 PM PT. > > > > > > > Please note that my availability highly depends on the specific > > > > > > > day, > > > > > as my > > > > > > > schedule is often fully booked with other meetings. > > > > > > > > > > > > > > Lev and Vladislav, please add your preferred times as well. > > > > > > > > > > > > > > Thanks, > > > > > > > Andrii Lomakin > > > > > > > > > > > > > > On Mon, Nov 24, 2025 at 5:14 PM Ken Hu <[email protected]> wrote: > > > > > > > > > > > > > >> Let's try to use an option that doesn't require an account (e.g. > > > > Zoom, > > > > > > >> Microsoft Teams, Google Meet). Cole, as a member of the PMC, do > > > > > > >> you > > > > > mind > > > > > > >> creating/managing the meeting for this open discussion? My > > > > > > >> preferred > > > > > times > > > > > > >> are anything between 8AM-8PM PT (16:00-04:00 UTC), but I have > > > > > > >> some > > > > > > >> flexibility and can extend beyond those hours. What time works > > > > > > >> best > > > > > for > > > > > > >> everyone else? > > > > > > >> > > > > > > >> On Fri, Nov 21, 2025 at 5:34 AM Andrii Lomakin via dev < > > > > > > >> [email protected]> wrote: > > > > > > >> > > > > > > >> > +Vladislav Grinin <[email protected]> upon his > > > > > request. > > > > > > >> > > > > > > > >> > Vladislav is working on TinkerPop LDBC benchmarks that we plan > > > > > > >> > to > > > > > > >> release > > > > > > >> > in the near future. > > > > > > >> > > > > > > > >> > On Thu, Nov 20, 2025 at 8:40 PM Ken Hu <[email protected]> > > > > 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. > > > > > > >> > > > >> > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Andrii Lomakin > > > YouTrackDB development lead > > > > > >
