RFC: Future::IO integration approach

[jjn1056]

Summary

PAGI 0.001016 introduces automatic Future::IO configuration in pagi-server. This is an experimental approach and I'm looking for community feedback.

Current Behavior

• pagi-server auto-configures Future::IO for IO::Async if Future::IO::Impl::IOAsync is installed
• This enables seamless use of Future::IO-based libraries (Async::Redis, etc.) under pagi-server
• Programmatic users of PAGI::Server must configure Future::IO themselves

Questions for Discussion

1. Is pagi-server auto-configuring Future::IO the right approach?
2. How should the PAGI spec address async ecosystem integration long-term?
3. Should servers declare what async backend they use?
4. Should there be a standard way for apps to discover async capabilities?
5. Are there alternative approaches we haven't considered?

Background

See the release blog post for full context on the tradeoffs considered:

• Libraries shouldn't configure Future::IO (they don't know the runtime context)
• Apps configuring Future::IO breaks PAGI's server-agnostic portability
• Extending the PAGI spec with async primitives risks scope creep
• Entry point (pagi-server) configuring it follows the "only entry points configure" principle

Related

• Future::IO: https://metacpan.org/pod/Future::IO
• IO::Async: https://metacpan.org/pod/IO::Async
• Conduit (Future::IO-native server): https://metacpan.org/pod/Conduit