What is the expected scope of this project? about twitch_api HOT 5 OPEN

I intend to cover Helix, TMI, PubSub data structures (no client), extensions, and (possibly) GraphQL. I do not intend to cover twitch irc (cough twitchchat ), Drops, or other third party APIs.

I'm unsure about undocumented features on endpoints, they would be good to have, but as expected they are not 100% reliable inregard to stability, currently the only undocumented feature is in the pubsub branch, but I think I want to implement some more helix endpoints that are used on the website.

I'm open to adding anything though, as long as it is directly affiliated with twitch.tv APIs :)

from twitch_api.

... I do not intend to cover twitch irc (cough twitchchat ), ...

Yeah, basically no one should bother tackling chat at this point since museun's got it covered better than any of us could 😆

I'm unsure about undocumented features on endpoints, they would be good to have, but as expected they are not 100% reliable inregard to stability,

Yeah, it would probably be good to have some sort of marker to make it obvious to users that a given endpoint is unofficial and may technically break at any moment, especially if you decide to start supporting more of them. Might actually be good to hide them behind a feature flag as well.

currently the only undocumented feature is in the pubsub branch

Aren't all of the TMI endpoints technically undocumented? Unfortunately there are basically no alternatives to get_chatters and get_hosts, and basically every bot in existance uses get_chatters, so hopefully they'll add them to Helix before decommissioning those... But AFAIK they're not officially documented anywhere.

I'm open to adding anything though, as long as it is directly affiliated with twitch.tv APIs :)

Cool. Just for reference, what about WebHooks or v5 (Kraken)? I know Kraken is deprecated, and it seems like Helix is getting much closer to covering everything that was missing so far, and there are a couple other crates that seem to cover it, though they are less maintained and currently the versions on crates.io seem to not even be building.

from twitch_api.

Oh, and should something be added to the README to make the planned scope more clear?

from twitch_api.

I'm unsure about undocumented features on endpoints, they would be good to have, but as expected they are not 100% reliable inregard to stability,

Yeah, it would probably be good to have some sort of marker to make it obvious to users that a given endpoint is unofficial and may technically break at any moment, especially if you decide to start supporting more of them. Might actually be good to hide them behind a feature flag as well.

Sounds good, one possible solution is to use deprecated tag or perhaps doing some css trickery (which would only be visible in docs). Gating them sounds fair.

currently the only undocumented feature is in the pubsub branch

Aren't all of the TMI endpoints technically undocumented? Unfortunately there are basically no alternatives to get_chatters and get_hosts, and basically every bot in existance uses get_chatters, so hopefully they'll add them to Helix before decommissioning those... But AFAIK they're not officially documented anywhere.

true :D

I'm open to adding anything though, as long as it is directly affiliated with twitch.tv APIs :)

Cool. Just for reference, what about WebHooks or v5 (Kraken)? I know Kraken is deprecated, and it seems like Helix is getting much closer to covering everything that was missing so far, and there are a couple other crates that seem to cover it, though they are less maintained and currently the versions on crates.io seem to not even be building.

Webhooks are part of Helix, so yes. For v5 Kraken, I guess this crate can provide some abstractions for it.

from twitch_api.

For v5 Kraken, I guess this crate can provide some abstractions for it.

Hey there,
hatmatter stopped maintaining his twitch_api crate/repository and I was somehow there in time, because I needed a crate, so I took over the of maintenance. I'm an beginner in regards of Rust, though coming from C/C++. But I started actively maintaining the crate again in my fork: https://github.com/age-rs/libtwitch-rs
I updated the outdated dependencies and changed the http client from hyper to a more high level one - reqwest, for easier maintenance.

As I saw you repository here, I was lowering the scope of the before mentioned repository to just maintaining the older Kraken API as long as it's needed/used. I think yours here and @Waridley effort to unify the Twitch API crates under ttv-rs is kind of interesting and I would like to contribute with parts(?) of the twitch_api/libtwitch-rs crates - if that's possible.

In the end I would like to mirror the ttv-rs main crate on the twitch_api crate on crates.io for easier discoverability - if that makes sense.

EDIT: Ah what I forgot: It might make sense to create an organisation here on github solely for this twitch api effort and all repositories or should it be managed from one repository overall? I think collaboration makes really much sense here. =]

from twitch_api.