I'm interested in playing a bit more with scripting Moi, probably in conjunction with some direct generation of nurbs objects -- I love Moi, but I want to play more with generative geometry. I'm a lot faster writing python code than I am JavaScript, and the pyOpenNurbs package is pretty good. I'm curious how difficult it would be to expose the JavaScript API to external callers, in real time? I could see, for instance, having the calling program actually launch the Moi instance and attach stdin/stdout text streams and interact with serialized commands/data, or doing the same thing over a named pipe or a local socket. I'm assuming that this would be a v3 thing, at the earliest, but even a fairly simple, hacked up version would be really useful. Thoughts?

/Ella

Hi Ella,

> I'm curious how difficult it would be to expose the JavaScript
> API to external callers, in real time?

This would be possible using the COM interprocess communication mechanism, but it can be a somewhat finicky thing to set up - it would probably involve some messing around with the installer to set up some additional stuff in the system registry and having a strategy for dealing with multiple versions being installed and stuff like that. It's not a very good time right now near the end of the beta cycle to mess with the installer very much though.


> I could see, for instance, having the calling program
> actually launch the Moi instance and attach stdin/stdout
> text streams and interact with serialized commands/data,
> or doing the same thing over a named pipe or a local socket.

Being able to mess with serialized data is pretty different than interacting with the script API though. It can tend to be easier to break compatibility when things are more directly interacting with binary data.

I think that making objects available as a blob of data that is actually an OpenNURBS 3DM file (same as if you saved it to disk) will probably be a pretty safe way to go with this though, since then it is serialized to a more stable format.

I do want to add that at some point, but that will be more work than just exposing an API, that will be about making a new binary data API instead of the script one basically. I'm not sure when that will start, hopefully in v3 sometime but even that is not really certain at this point.

- Michael

> This would be possible using the COM interprocess communication mechanism...

Hrm, yeah, COM would do it. That's really heavyweight as far as a way to interact with something goes; ok if you're working in .NET, say, but a huge pain from most other languages. I very much understand about the installer, etc., though; COM gets messy fast. Hence wondering if a flatter interface was possible. If not, though, then that makes sense.

> Being able to mess with serialized data is pretty different than interacting with the script API though.
> It can tend to be easier to break compatibility when things are more directly interacting with binary data.

I meant serialized data in the context of passing things in and out of the system -- if you make an API call, there has to be some way to return the data; if you're not passing objects around literally, you need some kind of serialization format. I didn't mean directly interacting with internal data inside the system, though. Basically, in addition to calling the existing API, there needs to be a way copy the current scene or objects in the scene out, and to paste new objects in.

> I think that making objects available as a blob of data that is actually an OpenNURBS 3DM file
> (same as if you saved it to disk) will probably be a pretty safe way to go with this though,
> since then it is serialized to a more stable format.

That would be pretty much ideal.

> I do want to add that at some point, but that will be more work than just exposing an API,
> that will be about making a new binary data API instead of the script one basically. I'm not
> sure when that will start, hopefully in v3 sometime but even that is not really certain at
> this point.

Ok -- I figured this would be a longer term thing, I just wanted to put it on the radar if it wasn't already.

/Ella

Hi Ella,

> Hrm, yeah, COM would do it. That's really heavyweight as
> far as a way to interact with something goes; ok if you're
> working in .NET, say, but a huge pain from most other languages.

Well, that existing JavaScript API that you were asking about is implemented as COM/Automation interfaces.

So the way it would be accessed would be through some form of COM interop mechanism.

COM has been around for quite a long time now on Windows, so it is pretty normal for languages to have some facility to access COM APIs.

Python seems to have plenty of stuff in this area, according to here:
http://oreilly.com/catalog/pythonwin32/chapter/ch12.html

See the section "Using Automation Objects from Python":



Doesn't seem to be too painful - it looks like once you have kind of connected it up you should be able to use it with a natural syntax.

That would be for accessing things like UI objects, services like point pickers, object pickers, etc...


> Hence wondering if a flatter interface was possible. If not,
> though, then that makes sense.

It does make sense to have a different mechanism for trying to hit large blobs of binary data more directly, that's not really covered in the current scripting API.

- Michael