Bring back support for sync requests

[sztomi]

Describe the feature or improvement you're requesting

92 says it introduces support for async, but it also seems to fully remove sync requests. This is a disruptive and likely undersirable change for applications that are not already async. Is there any chance to bring back support for sync operations?

Additional context

No response

[dongri]

I wanted to continue processing synchronously, but I changed to asynchronous because the library I was using had various flaws.

What specific inconveniences are there?

[sztomi]

What specific inconveniences are there?

• The Tokio dependency
• All functions interacting with openai-api-rs must be async
• ... which in turn means that pretty much everything needs to be async, since you cannot easily call async functions from sync functions (not without an async runtime)

My use-case is a simple CLI application that takes a ticket number and uses the OpenAI API to synthetise a branch name that describes the title of the ticket. This is a fully synchronous, it uses ureq to query the ticketing system, then uses openai-api-rs (3.0.1) to query OpenAI. While this is a small program and refactoring it to support async is not a huge deal, it introduces unwanted complexity, obscuring the control flow for no tangible benefit (it is always two, sequential requests that happen in the program).

[dongri]

@sztomi I see, understanding the challenge of depending on tokio can indeed make the program larger. However, you're struggling to find a good way to support both synchronous and asynchronous execution. Do you have any good ideas?

[sztomi]

I think the three main approaches that libraries take are:

• Depending on the async runtime anyway, and using that to provide a blocking interface (this is what reqwest does). This only partially solves the problem because the large additional dependency still exists and must be compiled.
• Code duplication and choosing implementations with #[cfg(feature = ...)]. This fully solves the issue for users, but it's an additional burden on you as the maintainer of this crate.
• Separating I/O from logic. This is likely the best, but requires the most effort to implement. It is possible to make the library HTTP client-agnostic and that allows users to decide what they want to use. This can be achieved by creating sync and async traits that represent HTTP clients and implementing adaptors for them. It has the added benefit of making the logic easier to unit test. You would end up with "_sync" and _async versions for the entry points (or different sub-crates) but there would be only trivial duplication.

In future Rust, keyword generics will allow solving this problem in a more elegant way.