/me raises hand
On Fri, Jul 10, 2026, at 12:46, C.J. Collier wrote: > On Fri, Jul 10, 2026 at 12:32 AM David Nicol <[email protected]> wrote: > >> >> On Fri, Jul 10, 2026 at 1:06 AM C.J. Collier <[email protected]> wrote: >>> >>> It would give modern cloud-native drivers a standard interface to target, >>> rather than everyone hacking their own custom event loops into individual >>> DBDs. >>> >>> Thoughts? >> >> >> Nice! The problem with event loops is that a system should have only one. Is >> there a thing like "async-check-and-do" that will do stuff or not block, >> that could get polled as part of an existing event loop? >> >> A quick search yields https://metacpan.org/dist/POE-Component-EasyDBI for >> discussion; POE wants to be the standard event loop services provider. >> >> I'm old-school and still write loops around select(2), which allows async >> comms with separate processes using a little language over a pipe, robustly, >> but that's no way to define a standard interface unless the facility gets >> wrapped somehow. The tradeoff of only polling after the select times out >> would be acceptable, I think, although it wouldn't be as responsive as >> including the protobuf system's file descriptors in the select set. >> >> I don't know if there is a standard for mapping a FD number to a >> [on-readable, on-writable, on-error] coderef triple, aside from just doing >> that with an AoA, but were I wanting to integrate an async system into an >> existing select loop, I could work with that. Especially if the system >> offered to take the same shape of data as an input for its own select >> loop.POE might have a standard for such things, I don't know. >> >> cheers >> >> dln >> >> >> -- >> "The profit motive is often in conflict with the aims of art." -- Ursula K. >> Le Guin > > David, thank you for reinforcing the importance of the single event loop. > That’s a fundamental constraint any enhancement to DBI must honor. > > Your insights, combined with the trend towards streaming protocols and > managed services in cloud databases (e.g., gRPC for BigQuery/Spanner, and the > native protocol for Cloud SQL for PostgreSQL > <https://cloud.google.com/sql/docs/postgres>), highlight the value of > standardized non-blocking operations within the DBI ecosystem. > > I’m mindful of the potential complexity and maintenance burden of introducing > new concepts into the DBI core. However, the complexity seems to be arising > anyway, but in driver-specific ways (e.g., `DBD::Pg`’s async features). > Without a common interface, we risk greater ecosystem fragmentation. > Centralizing the async interaction model within DBI, while keeping it > optional, could *tame* this complexity. > > Furthermore, DBI has a history of adapting beyond traditional SQL databases, > as seen with drivers like `DBD::CSV`. A well-designed, event-loop-agnostic > async interface could not only benefit SQL databases but also pave the way > for more performant and idiomatic drivers for other modern data systems, > including NoSQL stores, message queues, and real-time platforms, which often > rely on persistent connections and server-push. > > To what extent would the community be interested in formalizing an > exploration of this? I propose we establish a small working group to design > an optional, additive interface to the DBI specification. The goal would be > to offer a clear, event-loop-agnostic contract for drivers to integrate with > any external event loop. > > This would not alter behavior for existing synchronous code but would aim to > provide a solid foundation for the next generation of Perl database and data > source drivers. > > Is this a direction others would be keen to contribute to? > > Regards, > > > > C.J.
