I’m thinking, coding plugins in VBS, is really a bummer.
Non portable, insecure, OS permissions can be exploited.
What’s the point?
Python and C++ is both portable and safer to use in this context. I’m not saying it is portable no matter what, but the API’s are… So what’s the point with VBS?
VBS di per se’ isn’t any more or any less exploitable than Python. Both in fact have zero exploitability.
The security concerns might come from the COM layer eventually, which in XSI is needed for Python too anyway. If anything, if you run something blindly, Python could do even more damage since modules could be packaged that will do a lot more than what’s possible in VBS.
They are both cross platform as far as XSI is concerned, since both have the needed com layer provided in linux and windows both.
And for as long as the com layer will be there, VBS and JS have the potential to largely outperform Python in a limited number of situations.
Dev wise Python is the one that requires additional effort to deploy compared to JS or VBS for as long as XSI’s scripting API remains COM based.
Ok. Thanks for clearing that up.
I’ve never done any scripting for XSI (or any other package) so I didn’t know it was based on the aged COM interface.
Please don’t say that this is the case with C# as well? I mean, that’s one of the points of using .Net, right?
I’m fluent in C# and learning C++, and Ruby and Python, so I’m trying to find out how the scripting API’s for different applications work.
Softimage is as far as I know the only 3D package to support a .Net based API.
You are probably thinking of DCOM, COM+ and ActiveX.
COM is simply a set of standards and rulesets to implement and interface language agonistic objects, and it hasn’t been fully replaced by .NET in all regards yet.
It’s rather old but hasn’t been deprecated nor it will be in the near future according to MS, and .NET really only replaced parts of the whole lot, but the general idea of COM components is still alive.
To you as a programmer that it uses COM or .NET doesn’t make that much difference, since the API largely abstracts it anyway, and if you want to create your own lower level constructs you’d end up using the C++ API that (luckily) doesn’t require any COM or .NET crap.
The COM compliance is all on Soft’s side and of little to no consequence when you script. What I’m not that sure about is how much of the C# support was added with pure .NET and how much with the (limited) subset of things that are compatible between both .NET and COM.
What is your concern exactly?
Yea… I was a bit lazy before throwing out the post… you know, weekend and all.
I’ve skimmed through some of the API docs, and I have settled for doing multi threaded C++, with the Intel C++ suite of compilers. That should make some good, speedy plug-ins, when the need arises.
The whole GUI is abstracted in the API as well, so it should be consistent and not too difficult. This can again be wrapped in Python, to make user mods…
I’ve never done much COM / DCOM Windows programming, so I was just a bit unsure.
Tnx.
Chris
You should be fine then.
The COM side of thngs really is all on Soft’s side to offer the multi-language approach they do, from a user point of view the only slightly dodgy thing occasionally is dealing with pywin, which isn’t an MS implementation of the interface, but even then it’s actually a really good product in its context and it’s come a long way in the last few versions.
Most dispatching or component related issues are either gone or entirely transparent these days, and the object orientation qualities of Soft’s API are excellent compared to most of the competition and don’t clash with the language’s nature.
Python and C++ is pretty much all you need these days in my experience, and things tend to work well cross platform too.
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.