Rust SpiderMonkey debugger API

Goal: high level API wrapping CPP api to debugger

Question: should the rust bindings live in spidermonkey?

Home of the bindings

• nox: I would really like a safe API for the debugger in rust, but we have lower level bindings generated in our repository which is outside of m-c. The first step would be to move those bindings to m-c, or else how could you use them?
• jimb: Debugger API doesn't expose the debuggee values to the debugger. There's a membrane of objects that protect the debugger from potentially hostil code. A debugger written using this api never touches the objects of the debugger. Instead has Debugger.Object with reflection API. This doesn't depend on the JSAPI at all.
• nox: But if it depends on spidermonkey, how will we link against the bindings? First need to make spidermonkey a crate...
• jimb: Questions of linking are ones that I don't understand very well. I have the impression that things will be nicer if rust bindings live in spidermonkey. Moving rust-mozjs into spidermonkey is out of scope I think.
• nox: If you package rust code, it will need to be in a crate in spidermonkey, and it will need to link against spidermonkey. Either it needs to ship and supersede ours, or live standalone? This is my fear about writing a Rust API just for the debugger, since we still end up with linking issues even if it doesn't use the JSAPI.
• eddyb: The bindings for spidermonkey live in servo, right?
• nox: In another repo under servo organisation.
• eddyb: Since our higher levle API depends on those bidings, we shoul dideally ship the low level bindings with spidermonkey too. If we decide that moving the bindings is out of scope for this project, perhaps we should put the higher level API elsewhere.
• jimb: It's difficult for technical reasons to have rust-mozjs on the outside but another rust API on the inside. Everything is simpler if they're all in the same place.
• nox: Yes.
• jimb: This quarter devtools has switched to a different management process which has much more overhead. If we take on moving rust-mozjs into spidermonkey, it will not necessarily fit well with the new model. That's one source of hesitation; definitely policitcal rather than technical.
• eddyb: If we decide not to do the right thing immediatley, I don't think there's a high cost for doing it later. Just moving files, right?
• jimb: I think doing the wrong thing might be harder than it sounds.
• eddyb: Simplest possible thing right now?
• jimb: Put it in rust-mozjs?
• nox: Yes. Also, if you need to make changes to JSAPI, that can be difficult. Upgrading SM can be laborious because of linking issues and other things. I think making a C++ API fast then making low-level bindings from that, then building a high levle API on top of that when it works makes the most sense. This is why we want the bindings to be generated upstream.
• jimb: Are you carrying many local changes to SM?
• nox: Some windows ones are being upstreamed by glandium; then there are a few small ones that could be fixed in our binding tools.
• jimb: So you want to minimize these roundtrips because updates are hard.

API concerns

• jdm: This API uses utf-8 strings...
• eddyb: That's a good point. Do we need types to encapsulate translation?
• jimb: We'll need to deal with it, but I don't think it needs to be part of the public API. Just use Vec everywhere.

Summary

• jdm: So we'll be moving the high level API to rust-mozjs for the schedulable future?
• jimb: Yes. And the C++ API we'll build will be targeted at being easily FFIable.