Closed EIA485 closed 1 year ago
Including more Q&A's for completeness sake
VRChatAPI is generated from OpenAPI specification files (maintained by the people behind that project). Whilst there's nothing wrong with that in itself, it leads to less rust idiomatic code (I'm guessing due to the code generator not being able to infer things humans can with manual inspection). Some examples of what I mean by it not being idiomatic rust;
Debug
for structs containing secret tokens, meaning the tokens may get logged in debug logs, whereas I'll try my best to customize the Debug
and such implementations to not log the tokensSecondly, this project intends to be API client neutral.
If you take a look at chilloutvr_rs, you can hopefully get a general idea of what that means;
Providing a reference API client implementation, sure, but model the requests and responses in a declarative way where anyone can just implement their own small API client layer on top of the Queryable
trait.
I tried to find a generic crate for it, the closest I found was pretend but it seems unmaintained and doesn't support all the things I want, which sadly does mean consumers will need to implement the client abstraction layer themselves.
But it's way less code than re-doing all the API calls, if for exampel you don't like the blocking reqwest
calls which the vrchatapi crate is married to.
Which is also a part of the reasoning for this, I wanted the API client to be async.
And finally, this is still WIP, whereas the vrchatapi project is mature. But it also means that this project can make breaking changes and have an easier time being flexible. Also means that more contributors would be more than welcome & appreciated 😄
chilloutvr_rs, explains the mention of ABI. The base files for this repo were sloppily copied from that one. The mention has now been removed.
For more context: onlivfe is my actual reasoning for starting a new API client project. I thought about just moving all the API clients to a mono repo as well to avoid this kind of sloppy copy-pasting issues, but decided against it so that the API clients would be clearly separate projects, without seeming like they're tied to onlivfe.
We do not have any policies to define 'squatting', and so will not hand over ownership of a package for that reason.
The effect of which can for example be seen with the vrchat
crate.
I wanted to reserve a name for the project before working a lot on docs and such only to have to rename it by someone else taking the name in a similar fashion. If I somehow don't end up implementing this and years later someone is reading this issue, they can send me a message and I'll happily give up the name.
Marking as invalid due to being a question rather than an issue, in the future this kind of questions can be posted to onlivfe GitHub discussions library Q&A. Can continue the discussion at https://github.com/orgs/onlivfe/discussions/4 if required.
1, how is this different to vrchatapi/vrchatapi-rust