Remove `web` cargo feature

[nuzzles]

The web feature seems pointless, you could replace all instances of:

#[cfg(all(target_arch = "wasm32", target_os = "unknown", feature = "web"))]

with

#[cfg(target_arch = "wasm32")]

The reason I say the feature is pointless is because the web feature does not add or make decisions about implementation, it just allows it to work on wasm32, which could be handled with target_arch flags instead (no cargo feature necessary).

[dsgallups]

Unfortunately, wasm32 targets do not always run on the web. Usually, wasm32-unknown-emscripten will, but wasm32-unknown-unknown, wasm32-wasip1-* etc. have no guarantee of being web-based. The reason why the web feature exists is, when enabled, you imply two things:

1. Access to the web api. this includes the MIDI API + fix: use web_time for wasm #53's web_time dep. I will probably move to gate this under the web feature and remove the requirement to be wasm32.
2. Since the target is running in a browser, bevy will only run on a single thread (WebAssembly multithreading tracking issue bevyengine/bevy#4078)

This is critically important for MidiInput and MidiOutput. The underlying implementation of midir on the web contains a JsValue. Critically, JSValues cannot be shared between threads (worker threads in this case). See wasm-bindgen/wasm-bindgen#955.

However, since these Resource types will never change threads, it is safe to implement Send and Sync ONLY when the target is wasm32-unknown AND web is enabled.

Hopefully that makes sense!

edit: It is also theoretically erroneous for midir to be doing this.

[nuzzles]

I see... So the web feature is signaling that we intend to compile for web targets, and wasm32 is not guaranteed to support the MIDI API, etc.

Do you have any plans to support a no-std variant of wasm32 like wasm32v1-none? If not, it could be assumed on wasm32 you are building for web, and the README could say "midix works out of box on wasm32, but depends on the MIDI api available in Web browsers." Additionally, if the MIDI API is not available in the plugin being built, we can throw a panic to let developers know this.

[dsgallups]

Yes! In theory, midix already meets this requirement. I say in theory, because I've never needed to use this target. However, because it's no_std, I'm guessing that the requirement for the alloc crate is fine. But, it's a strong opinion weekly held. If you've got an opinion on this, please share!

However, there are a few design problems with bevy_midix to allow this. Robust support for multi-targets is not my expertise yet. I probably will consult with another library dev on the best path to do this. I think the suggestion about panicking is a good idea, so +1 on that in the meantime :)

So really, when I have this web feature, it's not that I assume it to be perfect, or even correct. I probably will use fragile to handle the thread sync issue or refactor.

Notes I realized were completely off topic so I've moved them to the bottom

Strong opinions weekly held:

1. The MSRV of this crate is the current version of rust. Most likely, the MSRV for the next while will be 1.87 (there've been many const fn stabilizations, particularly with core::str::from_utf8 and core::str::from_utf8_mut). That being said, I haven't actually run cargo-msrv on the project yet. const capabilities are really important imo. Ideally, one should be able to parse an entire file at compile time. No lazy statics.
2. I believe almost all tier-2 targets have heap support. While there are some ergonomic issues with reading, I think there is a better use case for using Cow<'_, [u8]> over two separate owned and borrowed modules (like how ttf_parser does it. However, Cow usually implies a heap exists.
   If this assumption is erroneous, I could make an alias that is feature gated across types.
   maybe something like

#[cfg(feature = "alloc")]
type Bytes<'a> = Cow<'a, [u8]>;
#[cfg(not(feature = "alloc")]
type Bytes<'a> = &'a [u8]; 

The thing is, I'm not using this Cow for its mutable properties. I'm using it so I don't need to write two identical variants. But, if I find this current alloc requirement too much, I'll know soon on this embedded device in hand.

There's also the fact that this project really is still in development. I might have jumped the gun a little bit on moving the major version, because v4 has a lot of breaking changes.

and on that note, I'll need to write a more detailed migration guide...

Final edit: I think that there are only a few principles I'd like to adhere to for this crate. I'll move this somewhere else. Thank you for your interest, seriously!

1. It should be trivial for someone that doesn't know anything about MIDI to use it. Clear language everywhere. Bytes never necessary. I'm slowly losing what that means as I become more acquainted with the standard. Performance cost is wholly worth the clarity.
2. This crate should be as consistent as resvg parsing svg. Handle edge cases by deferring to some other understanding of what an inconsistency implies. Grossly failing at this right now. What an amazing crate.

[dsgallups]

Do you have any plans to support a no-std variant of wasm32 like wasm32v1-none?

Update: I've made issue #59 for this. bevy_platform seems really promising for quick no_std transfer. But would need to await a plugin for handling audio I/O. bevy_audio doesn't allow this yet, and would probably need a feature for midir. https://bevyengine.org/news/bevy-0-16/#bevy-no-std-support

[dsgallups]

I'm closing this due to the changes made in #69. Reopen this if you find there to be issues after #54 is fixed :)