onlivfe / vrc_rs

VRChat's API in a rust idiomatic way (unofficial)
Mozilla Public License 2.0
6 stars 2 forks source link

few questions #1

Closed EIA485 closed 1 year ago

EIA485 commented 1 year ago

1, how is this different to vrchatapi/vrchatapi-rust

  1. why does the repo for a vrc api client mention abi?
ljoonal commented 1 year ago

Including more Q&A's for completeness sake

1. How is this different to vrchatapi/vrchatapi-rust?

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;

Secondly, 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 😄

2. Why does the repo for a vrc api client mention abi?

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.

3. Why this is already published without implementing pretty much anything?

crates.io:

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.

ljoonal commented 1 year ago

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.