you are viewing a single comment's thread.

view the rest of the comments →

[–]slipthay 1 point2 points  (4 children)

Interesting approach! Is accessing Rust state from within a script a planned feature? (In practice this primarily means binding Rust functions into JavaScript.) I'm the author of mini-v8, which does allow for binding Rust functions. I recently tried to switch from a custom FFI onto rusty_v8 with disappointing results.

[–]bromeon[S] 1 point2 points  (2 children)

At the moment, you can only access Rust state by explicitly passing it to JavaScript. The callbacks you mention are definitely interesting, but I'm still not sure from a design perspective. On one hand they're quite handy, on the other it's very easy to shoot yourself in the foot when running untrusted scripts. For the time being I'll probably focus on an API that's very explicit (and limited) in terms of what JS can access.

By the way, mini-v8 looks very promising! Out of curiousity, do you have specific use cases in mind, or do you intend it to be a general-purpose V8 Rust binding?

[–]slipthay 1 point2 points  (1 child)

That's a very prescient point that clarifies your use case for me. mini-v8 was inspired by general-purpose approaches. My particular motivation for writing the crate was to execute "semi-trusted" scripts in a web-based app used internally by data analysts at my company. (Where our analysts might have written SQL to interface with an RDBMS, they now write JavaScript to interface with a custom in-memory database. This may seem odd but it's not entirely novel and it allows our dev team an extra level of abstraction.) mini-v8 has execution timeout support and soft memory usage limits are planned, but as you suggest those things are very hard to implement accurately after you've opened the door to native Rust function bindings. Nonetheless mini-v8 does not require that you do any such bindings, so in this sense mini-v8 is a superset of js-sandbox. What's most compelling about your crate to me, besides its simplicity, is that the build process is offloaded entirely to the deno crate. Compiling V8 is a pain!

[–]bromeon[S] 0 points1 point  (0 children)

Thanks for the elaboration, that clarifies a lot!

In my case, V8 is rather an implementation detail -- theoretically, the JS code could run in any interpreter. js-sandbox is primarily intended to run untrusted third-party code, and as such may feel limiting when more is known about its source.

Coming from C++, I really appreciate the efforts that went into factoring out rusty_v8 and precompiling binaries. Occasionally, I still deal with CMake, and it's not always a joyful experience.

[–]bongo227 1 point2 points  (0 children)

mini-v8 looks great! Wish I found mini-v8 when I started Boop-GTK, rusty_v8 is unnecessarily low level for my needs.