Ah, that does seem like it will solve the problem. Thanks!

Not sure I understand. What I’m trying to do is something like this:

• Poll a stream which takes fedi events. Read player commands.
• If an event comes from a known player, check which match they are into.
• With that info, get their opponents/coplayers etc and perform the change of state in the game (send replies, next turn, etc).

So what I have as a key is a player name (AP username) and from that I need to find which match they’re in.

There’s nothing semantically useful about a match ID.

Thanks, the RC is a possible approach. It seems to violate DRY a bit but maybe there’s no way around it.

The reason I had the players outside the match is that I need them there anyway, because when I get a player action I need to check in which match they are, who are their opponent(s) and so on. So even if they’re in, they’ll have to be out too as there are concurrent matches and the player actions come all through the same network stream.

I can think of alternatives. For example, the server could keep the user’s private key, encrypted with a passphrase that the user must have. So key loss wouldn’t be an issue. (Yes, passphrase loss might, but there are lots of ways to keep those safely already, compared to key material which is difficult to handle.)

Possibly yes. I’ll check if the results are equivalent.

Apparently the problem is due to an incompatibility between the use of certain libraries (winapi and windows-sys) which use different versions of COM. At least so I deduce from the documentation I’ve read.

There’s a workaaround:

On Cargo.toml, use.

[build-dependencies]
embed-manifest = "1.3.1"

And on the root of the project (not the src dir) create a build.rs file with the following content:

use embed_manifest::{embed_manifest, new_manifest};

fn main() {
    if std::env::var_os("CARGO_CFG_WINDOWS").is_some() {
        embed_manifest(new_manifest("Contoso.Sample")).expect("unable to embed manifest file");
    }
    println!("cargo:rerun-if-changed=build.rs");
}

This embeds a manifest together with the executable, solving the issue.

Same erro by using this approach.

Tokio works fine, by itself. windows-native-gui works fine, by itself. It is the combination that causes this issue.

The way I look at this is I have a reasonable understanding of rust. I’m not an expert but I can more or less do whatever computation I need to do, use crates, and so on. But with async it’s like learning another language. Somewhat of an exaggeration, but it’s not just what code you need to write, but also being able to read the error messages from the compiler, understanding the patterns and so on. So yes, it’s probably fine, but it does take work.

So probably the tokio mpsc channel, right? Why is it not possible tu use normal sync channels? I’ve read about it but I don’t understand the reason.

Also I’m thinking of spawning a thread to do this part, or should it run on the tokio main function?

I generally agree, though I could be convinced of recurring payment in the case of high speed APIs that need a lot of updates to keep working. Chasing an API can be a lot of work.

Of course, a solution to that is having an up-front payment and letting people update as they wish–if there’s new value in the new releases presumably they will.