AnthonyMusgrove
commented
4 years ago G'day again mate, these are great questions, and I'm so happy to be able to answer them. So far:
- Safe to assume it's Node.js under the hood? Unfortunately not yet! Integrating c# with node.js is possible, however support for dotnet core isn't ready yet (I'm planning on using Edge.Js), as soon as it's ready for dotnetcore you can bet your bottom dollar that I'll be jumping straight onto it.
At the moment, under the hood the Javascript engine is ES5 and partially ES6 compatible. It's using the C# Jint library, you can check it out here: Jint Library
I'm continually watching for the release of EdgeJS with dotnetcore and I'll be integrating it very thoroughly!
-
What access to the system do we have? The same access as the Emby user at the moment. It basically extends from the running emby core. It's relatively new though, so I am way way way more then happy to integrate functionality to suit projects that people would like to build
-
For example, if I wanted to go querying the user's file system, can I do that? Can I spawn other processes?
Absolutely. I can also integrate FileIO functionality into the ScripterX object, which is basically a direct-line access to the exposed CLR from the plugin, I call them Contexts, and I add functionality to the exposed CLR where I see needed, however because it is only new, I know there is far more that can be integrated, and I'd love some suggestions so I can get them in there :)
-
Or are we running in some kind of restricted sandbox? If so, what are the restrictions? The execution environment that is spawned for an individual package gives bounds to the global scope of that individual package, so at the moment a package wouldn't be able to communicate with another's code directly, which is generally how I think you'd want it anyway.
-
I see there's a ScripterX namespace with an http client, for example. Is this for convenience or are we prohibited from doing our own http calls use node.js (again, assuming it's node.js under the hood)?
Absolutely for convenience. Emby has an exposed IHttpClient that I integrate with for web get, post, etc. I wrap this into a context called PackageContext_WebClient, and expose an instance of it via the ScripterX context called Web. So essentially Web.Get/Web.Post are simply c# functions on a c# object that handle the underlying IHttpClient.
The email context (ScripterX.Email) is also a wrapper called PackageContext_Email, and exposed as ScripterX.Email, and utilises MailKit/MimeKit for its underlying functionality, which is pretty neat.
- What about access to the Emby api from within this javascript env? Or are we just to make raw http calls? Would be nice if we could access the api thru this ScripterX object.
You could absolutely make calls to the Emby API using the Web.Post functionality, however I love this idea, and we should make it seamless. I think possibly another context for example PackageContext_EmbyAPI, expose it as ScripterX.EmbyAPI and include direct functionality to the API - this is a fantastic idea and I think we should integrate this!
-
More formal api docs for this ScripterX object in the js env. Yep, this is something that I most certainly need to piece together, and quickly!
-
More details about the js env itself I hope that what I've given you so far is helpful, but I agree that integrating Node.JS will definitely be this plugin's future core Javascript engine, as soon as its supported on dotnetcore (Check out EdgeJS at EgeJS
-
Access to the emby api from this js env Absolutely, this is something that I am going to work on very quickly.
"As you might guess, I'm in the early stages of a project of my own and integrating with ScripterX seems like it's going to save me a lot of work, especially this Packages idea. Just trying to get as much info about this env before I decide to go with developing a Package vs. just installing a series of actions for the various events."
I absolutely love that you have found a use for my plugin, I enjoy working on it thoroughly and if I can be of any help whatsoever to making your project easier to integrate into the plugin and emby, etc I am all ears, and I am more than happy to help. Thank you so so so very much for your feedback, I appreciate it so much.
Is your feature request related to a problem? Please describe. Looking for details on the JavaScript engine/env available for Packages. Safe to assume it's Node.js under the hood? What access to the system do we have? Does our js run with the same access rights as the Emby server process? For example, if I wanted to go querying the user's file system, can I do that? Can I spawn other processes? Or are we running in some kind of restricted sandbox? If so, what are the restrictions?
I see there's a ScripterX namespace with an http client, for example. Is this for convenience or are we prohibited from doing our own http calls use node.js (again, assuming it's node.js under the hood)?
What about access to the Emby api from within this javascript env? Or are we just to make raw http calls? Would be nice if we could access the api thru this ScripterX object.
Describe the solution you'd like
Describe alternatives you've considered n/a
Additional context As you might guess, I'm in the early stages of a project of my own and integrating with ScripterX seems like it's going to save me a lot of work, especially this Packages idea. Just trying to get as much info about this env before I decide to go with developing a Package vs. just installing a series of actions for the various events.