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

Reply via email to