Plugin Wasmtime: Debugging Info & Notes and References

- Notes about debugging with debugger and with core dumps.
- Add notes about versioning to wasmtime advantages.
- Add Extism as a reference project.

developer/src/plugin/wasmtime/advantages.md

@@ -24,7 +24,9 @@ Wasmtime is part of a suite of crates and tools designed around Wasm, Wasi, and
 - Error at compile time if the host and or the plugin doesn't fulfil `wit` file contract.
 - We can define a single API on the host for the producer functionality. This API can support standalone plugins with custom implementations for data source and parsing. Additionally, it can be used with composed source and parser plugins.
 - Plugins are compiled as libraries and don't have to have their own runtime and main function. 
+- Versioning can be easily resolved by defining different `wit` files for each version. Any error with version-mismatching will be discovered early by loading the plugin file directly. There are many examples for versioning in `Zed Editor` and `Verloren Games`.
 - Many Projects are using it and can be used for references. 
   - [Zed Editor](https://github.com/zed-industries/zed): Uses the component model and compile the plugins in run-time. Good source to check how version compatibilities problem are solved.
   - [Veloren Game](https://github.com/veloren/veloren): Multiplayer voxel RPG. It uses the component model for the plugins as well.
+  - [Extism](https://github.com/extism/extism): Framework for building with WebAssembly. They have their own memory approach and have a lot of tweaking for wasmtime default configurations, besides using host functions as pointers. They don't use component model approach though.
   - [Lapce Editor](https://github.com/lapce/lapce): Using Wasi version 0.1 without the component model.

developer/src/plugin/wasmtime/notes-tips.md

@@ -4,3 +4,7 @@
 - Copying the memory doesn't seem to be the bottleneck, as we got almost nearly identical performance to native code in a simple data source implementation. 
 - Frequent calls to Wasm methods from the host have a noticeable negative impact on performance. It's advisable to minimize these calls and cache data whenever possible. In the case of the parser, calling the plugin method each time parse is invoked, without unnecessary data copying, resulted in a performance that was 6 times slower than native code with asynchronous execution. Temporarily removing the asynchronous code reduced the performance difference to 1.6 times, but it still worse than the caching solution even with async as the results are about 1.35x only. 
 
+## Debugging
+- Generally, it's possible to debug the plugins directly from the host for standard wasm plugins without the component model feature. Debugging must be enabled in the engine configuration. Here is a link to a [working example](https://docs.wasmtime.dev/examples-rust-debugging.html).
+- However, breakpoints cannot be resolved when using the component model with the `wasmtime::bindgen` macros on the host and `wit-bindgen::generate` on the guest. There is no documentation about this yet; it might become available in the future or with more in-depth investigation.
+- There is other possibilities for debugging using [Debugging WebAssembly with Core Dumps](https://docs.wasmtime.dev/examples-debugging-core-dumps.html), to create core-dumps on errors. Here is [an example](https://docs.wasmtime.dev/examples-rust-core-dumps.html).