Native Python API

[nrusch]

Hey Chris,

I should have been more clear in that my hope for an eventual transition away from Mono is not based on any current issues I have been encountering, but more on the potential implications it would have for long-term feature development and expansion. I’m also not suggesting it should be made a top priority in any way, but it’s almost certain that as you continue to gain adopters running Unix-based facilities, you will also continue to hear more and more noise about removing the Mono dependency. I do understand how big of an undertaking it would be, and that there would likely be significant fallout in terms of stability and the potential for feature stagnation, but I’m thinking on a pretty long timeline here, and mostly about the potential for continuing to improve Deadline as a toolset.

Here are a few “food-for-thought” items:

• One thing that has been mentioned on more than one occasion is the idea of creating a modular framework for job scheduling plugins. Sure, these could be implemented by users in pure Python and made to run in Python.NET, but speed/efficiency would be a concern. Maybe it would be possible for these to be compiled platform-native libraries and still work with .NET though…
• I would be willing to bet that quite a few users would rather have a native Python API to the Deadline repository than the deadlinecommand tool. On top of making tool development much simpler (and speaking from experience), this would be huge for studios wishing to implement their own complex application plugins; it would allow any application running its own Python interpreter (Maya, Nuke, RV, etc.) to communicate directly with the repository, rather than having to implement a custom job plugin with log parsing handlers and then emit all of the proper messages to trigger things. deadlinecommand could then be converted to simply operate as an executable front-end to parts of the API.
• Mono creates another layer of obfuscation in front of any problem, and introduces its own dose of bugs into the Deadline codebase without anyone lifting a finger. There were quite a few instances during the 6.0 beta process where errors would originate from Mono, or some bug in the runtime would cause programs to crash.

I’m saying this as the owner - but please explain to me other than from a sense of purity and historical issues - if we continue to have no issues, would you still insist on removing Mono?

Again, I’m not insisting in any way, but I keep seeing a lot of potential for Deadline to become much more powerful and flexible, and thus more attractive to studios with heavy investments in custom code, and Mono is one thing that will inevitably make that more clumsy/difficult. One question I would be curious to hear thoughts on is, is anything actually gained by using Mono? In other words, does it provide any serious advantages from a development standpoint that a platform-independent combination like Qt/Boost wouldn’t?

now, i’m not saying we can’t have some top-secret-future-definitely-not-right-now-project to rebuild the codebase thoroughly in C++, but i just dont see how spending those resources doing that today or even this next major version cycle would be beneficial to us or you. please feel free to educate

Top-secret-future-definitely-not-right-now is all I’m really hoping for at this point.

Thanks for keeping a discussion going.

-Nathan

[cbond]

thanks for the thoughtful feedback.

out of curiosity, and throwing a boomerang at you - would there be interest in supporting something like KL [fabric engine] in Deadline?

cb

[nrusch]

I guess it depends on what you mean by “supporting” it.

Fabric still seems like a toss-up as far as whether it’s really worth investing in, since its long-term future is still very much unknown. At this point, the place it seems most useful is as a plugin to something like Nuke or Maya (a la their Creation Splice demos). With that in mind, it’s hard to see what Deadline would really gain from supporting it directly, though again, that may depend on what sort of integration you’re talking about.