> 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