PDK compiler could be packaged into SDK?

[benwiley4000]

Hi, I'm new to this project but it sounds really promising. I'm not aware of other projects that seem so well suited to supporting arbitrary user code in, for my case, a web app. I investigated iframes first but there didn't seem to be a great way to send and receive messages with an arbitrarily defined iframes, while restricting access to local storage, indexeddb, etc.

My main goal with the plugin system I'd like to add to my app, is to allow users to quickly write a simple JavaScript (or other) function and upload it. I would love to avoid making users download the PDK to test their stuff. I wondered if it could be possible to have (as part of the SDK or as separate packages) the plugin compilers, so a user could upload some JavaScript in the browser, and it instantly gets compiled to wasm and then installed as a plugin.

[bhelx]

@benwiley4000 thanks for your interest!

I wondered if it could be possible to have (as part of the SDK or as separate packages) the plugin compilers, so a user could upload some JavaScript in the browser, and it instantly gets compiled to wasm and then installed as a plugin.

At this very moment, no it's not possible. To explain why, let me quickly outline the main components of the PDK compilation process:

• We use rust and wasi-sdk to compile a quickjs interpreter into a wasm module
• We eval your js code inside that module by passing it in through stdin
• We use wizer to save the state and dump back to wasm

Getting all this to work on the web would be pretty tricky. I haven't seen anything that can compile to wasm that also runs on the web. The closest I've seen is someone experimenting with running the Go compiler in wasm.

This does not mean all hope is lost. One thing you could possibly do is use our PDK as a general js sandbox by basically just exposing eval. I outlined this technique in the blog post Sandboxing LLM Generated Code with Extism. You could possibly adapt this technique. All you do is export a register function which takes in and evaluates a JS module as text. Then export an invoke function to invoke it. This isn't the most ergonomic or performant way to do it, and whether it would work will depend on your use cases, but it could be used to get your system started if you want to try something today.

[benwiley4000]

Ok I'll check that out thank you. I have a question, I know some of the API is considered unstable and will change. Should I expect that plugins that were previously compiled to wasm with the PDK might stop working in a newer version of Extism ? Le lun. 16 oct. 2023, 9 h 37 a.m., Benjamin Eckel ***@***.***> a écrit :

…

@benwiley4000 <https://github.com/benwiley4000> thanks for your interest! I wondered if it could be possible to have (as part of the SDK or as separate packages) the plugin compilers, so a user could upload some JavaScript in the browser, and it instantly gets compiled to wasm and then installed as a plugin. At this very moment, no it's not possible. To explain why, let me quickly outline the main components of the PDK compilation process: - We use rust and wasi-sdk <https://github.com/WebAssembly/wasi-sdk> to compile a quickjs <https://bellard.org/quickjs/> interpreter into a wasm module - We eval your js code inside that module by passing it in through stdin - We use wizer <https://github.com/bytecodealliance/wizer> to save the state and dump back to wasm Getting all this to work on the web would be pretty tricky. I haven't seen anything that can compile to wasm that also runs on the web. The closest I've seen is someone experimenting with running the Go compiler in wasm. This does not mean all hope is lost. One thing you could possibly do is use our PDK as a general js sandbox by basically just exposing eval. I outlined this technique in the blog post Sandboxing LLM Generated Code with Extism <https://extism.org/blog/sandboxing-llm-generated-code>. You could possibly adapt this technique. All you do is export a register function which takes in and evaluates a JS module as text. Then export an invoke function to invoke it. This isn't the most ergonomic or performant way to do it, and whether it would work will depend on your use cases, but it could be used to get your system started if you want to try something today. — Reply to this email directly, view it on GitHub <#516 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADHOD3JAM55ADYMFI2GKH53X7U2DJAVCNFSM6AAAAAA6BTSEXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRUGUYDIMZQGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nilslice]

@benwiley4000 -

This is actually a great time to start an Extism project, as we're moving toward v1.0 by end of the year. The PDK versioning should retain compatibility for quite a long time, once this PR is complete: #504

We also have a longer-term compatibility + versioning scheme, which has not yet been implemented. However, if you'd like to take a look and consider providing feedback, we'd appreciate it!https://github.com/extism/proposals/blob/main/EIP-005-extism-versioning-system.md

In any case, I would keep a close eye on #504. The crux of the current state is that:

• plugins built before that PR will need to be re-compiled
• plugins built after that PR will be compatible for a long time

Also, follow the #development channel in our Discord too, where we'll be active about this topic. https://extism.org/discord

[benwiley4000]

Alright thanks so much for that info! Ben Le lun. 16 oct. 2023, 11 h 41 a.m., Steve Manuel ***@***.***> a écrit :

…

@benwiley4000 <https://github.com/benwiley4000> - This is actually a great time to start an Extism project, as we're moving toward v1.0 by end of the year. The PDK versioning should retain compatibility for quite a long time, once this PR is complete: #504 <#504> We also have a longer-term compatibility + versioning scheme, which has not yet been implemented. However, if you'd like to take a look and consider providing feedback, we'd appreciate it! https://github.com/extism/proposals/blob/main/EIP-005-extism-versioning-system.md In any case, I would keep a close eye on #504 <#504>. The crux of the current state is that: - plugins built before that PR will need to be re-compiled - plugins built after that PR will be compatible for a long time Also, follow the #development channel in our Discord too, where we'll be active about this topic. https://extism.org/discord — Reply to this email directly, view it on GitHub <#516 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADHOD3NISQQBWN2FYVFDKDLX7VIRTAVCNFSM6AAAAAA6BTSEXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRUG43DMMBRGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[benwiley4000]

FYI for now I am using a system based in iframes. I was able to get it to work with an iframe serving a separate html file on my own domain, with sandbox="allow-scripts" and a restrictive CSP meta tag in the html file, which accepts only script evals. I like this solution because it gives users access to the Web Audio API - my application is for audio.

However I am going to keep an eye on Extism, I think it has a lot of potential especially because it supports so many languages.

[nilslice]

Going to close this for now, but please feel free to re-open if you visit this again

[morgante]

FYI we also would like to have a compiler packaged into the SDK.

[nilslice]

@morgante - hey! interesting -- would you elaborate about why and which SDK?

[morgante]

We ship a CLI to our users and have historically had problems with any dependencies we introduce—the CLI itself is a static binary.

We'd like to embed arbitrary JavaScript or AssemblyScript code into the GritQL language, but without requiring additional dependencies.

Ideally it would be JavaScript PDK + Rust SDK.

[bhelx]

@morgante Our javascript PDK is a rust project. There is a CLI crate but I assume you'd be able to use it as a library. That's not something we explicitly support but I'd be happy to help you figure it out. All the pieces are in rust (with the exception of the quickjs code which is a c project wrapped in rust).

[bhelx]

Note you may need to kind of copy some of the stuff the CLI crate in that project is doing. But it's not much code. We could work on exposing it as a library and supporting it if it works for you.

[nilslice]

oh, @morgante, sorry if you were also the person I was talking to on Discord! didn't connect the grit dots :)

let us know if the JS PDK works for you as a library.. if you end up needing something specific, please open issues on that repo!

[morgante]

Thanks! It doesn't look like you have it published though? I think we need a lib.rs to be able to import it. Obviously I could copy and paste from the CLI code, but I'd rather avoid forking.

[bhelx]

@morgante no, i don't think we've published it as a crate. I don't think it's going to just work as is. If you could just pull it from github and do some experimentation to confirm it's possible, I'd be happy to take what you learned and change the codebase to support it. I just want to make sure it works for you first. Of course let me know if you get stuck or need help. Discord is the best place to reach out and i'm available anytime.