async-openai
async-openai copied to clipboard
64bit
FIleInput from memory
I am trying to understand how to upload a file with contents from memory and can't figure out how. It appears that file input is only from a file? Do I have to save my bytes to file system to read them back?
My overall goal is to upload a file my program receives, from an incoming network request to an assistant thread.
In current design files are only read from filesystem.
File uploads from in-memory sounds like a good feature to add.
@64bit I am looking for the ability to add audio data vecs to AudioInput instead of having to write them to a file first, would this be something you'd be interested in a PR for?
Absolutely interested!I think having this feature would work same for bunch of inputs: FileInput, ImageInput, AudioInput. Looks like they need to be enum to support paths and bytes?
Regarding PR: for non trivial features like this one it really helps to have a new self contained example because it becomes easy to test new feature and old examples.
Could you accept io::Read instead, not a Vec? I'd like to be able to pipe data from a network request to OpenAI without having it buffer it neither in the file system, nor memory.
Hey @nodir-t @64bit , I put up a PR which works for in-memory files (Bytes and vec[u8] as that's what reqwest::Body accepts), but I wasn't able to figure out a way to get these inputs to take an io::Read as it seems reqwest::Body wants AsyncRead. I tried having these Inputs accept a generic that was AsyncRead but got confused as to how that would work with the derive_builder builder which would require the AsyncRead instance to be Clone as well. I'm fairly new to Rust and open source PRs so any feedback would be much appreciated!
hey @Prosammer , thank you I was able to check it out today and it looks good given that its backward compatible change for consumers of library happy to merge it.
I'll keep this issue open for the context and if someone wants to continue work on AsyncRead and io:Read suggested in this thread.
This seems coincidentally solve some issues for wasm support, as I was planning to do this here. Thanks @Prosammer! If you have some time and interest, you can take a look at the experiment branch and help mature the wasm support.
@ifsheldon haha awesome, I'm not very familiar with wasm but I will take a look!