[Maya-Python] Interest in RestMEL

156 views
Skip to first unread message

Marcus Ottosson

unread,
Nov 3, 2014, 4:38:22 AM11/3/14
to python_in...@googlegroups.com

Hi all,

Is there any interest in a RESTful interface to Maya?

The idea would be to facilitate external access of Maya from things like Web Applications or externally running GUIs.

I mocked up a minimal example of how it could look here:

# List all nodes
import requests
print requests.get("http://127.0.0.1:6000/node").text

The Demo includes an externally running QML application.

Alternatives

What would be the benefits of something like this over the native commandPort or ZeroMQ and c/o?

  • commandPort uses the same port for multiple instances of Maya, causing only the first instance to get exposed. Can this be remedied? What else is there about the commandPort that could be better?
  • ZeroMQ relies on a binary library and isn’t as supported as plain HTML. Meaning a web application could gain access to Maya via native commands, whereas talking to a ZMQ server requires third-party binaries.

Thoughts?

Best,
Marcus

--
Marcus Ottosson
konstr...@gmail.com

Justin Israel

unread,
Nov 3, 2014, 6:06:55 AM11/3/14
to python_in...@googlegroups.com
Hi

Here are my 2cents...

The commandPort is kind of like a specialized application running to specifically expose the command API (MEL or Python). I would say if your goal is to control Maya through its own API, then the commandPort is meant for that and is the easiest because it is automatically served for your by Maya. You can also open the commandPort on different port numbers, if you need to run more than one Maya. How you orchestrate them choosing their port at startup is a something you would have to figure out. But it is the same problem you would have with tcp or http since applications must bind to unique ports on a host. 
The downside of the commandPort is that it is clunky for anything specialized. 

Between ZeroMQ or http, or even plain raw sockets, they kind of fall into the same group and I think it would just be a matter of who you want to expose a service to. If we agree on my previous point about the commandPort being a ready-made access to the Maya commands api, then it means tcp/http would be lower level and that you would have to do more work to get to the same point as the commandPort. That being said, I think it is much better suited for writing specialized access for a custom application that intends to use its own protocol as opposed to control Maya through its API. ZeroMQ happens to have a lot of neat tools to express different communication patterns. In some use-cases it could be interchangeable for an http interface. 

So all in all, I would say that a tcp/ZeroMQ/http/RESTful interface into Maya may only be useful if it is solving a specific application's implementation. Otherwise it would just be replicating something that is already there in the commandPort. And if you really wanted to export the Maya commands interface over http, you could probably get away with much less work than exposing a full coverage RESTful interface, by just accepting http requests to a certain port, with a defined json format, that could be dynamically mapped to the commands API. You probably don't even need flask for it. 

- Justin


--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODWwbwoQyVE1o_f0LvcC2DF%3Dfv1bCVA8vznHet8wqBy%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Marcus Ottosson

unread,
Nov 3, 2014, 6:58:31 AM11/3/14
to python_in...@googlegroups.com
Thanks for your input Justin!


For more options, visit https://groups.google.com/d/optout.



--
Marcus Ottosson
konstr...@gmail.com

Eduardo Grana

unread,
Nov 3, 2014, 10:37:37 AM11/3/14
to python_in...@googlegroups.com
Hello Marcus,

I remember long ago, i maya there where an web interface, where you could pass commands from the
web browser, cant remember well, but was something like mel:// and your command.
I think it still there, but it is not enabled by default due to security issues,
Have you given a try to that?
What do you think about security in your proposal?

Here I go again with an off topic, i ask for forgivness in advance.
Is there any easy - open source -tool to do those "screen captures turned into gif" you usually post? 
they are awesome and worth a thousand words, and I love to use them when explaing stuff over an email.
Thanks!

Cheers,
Eduardo


For more options, visit https://groups.google.com/d/optout.



--

Eduardo Grana

unread,
Nov 3, 2014, 10:40:03 AM11/3/14
to python_in...@googlegroups.com
sorry, i sent the wrong link,
anyway, search "web browser" on that link and you get where i was...

--

damon shelton

unread,
Nov 3, 2014, 12:09:56 PM11/3/14
to python_in...@googlegroups.com
I have been using redis for my application communications. http://redis.io/
All the communication happens through a redis server, with callbacks in your program listening on redis channels (these are defined in your program - eg. rchannel = 'foo:bar') Redis then passes around key,value pairs.
What is nice is that it allows back and forth communications, not just 1-way and allows for any program that can run python can then send commands between each other. So I am able to create newer Qt apps and QML apps and have them control things in maya and vice versa. Makes it so I am not completely stuck with just Maya's versions of python and Qt. I can even execute commands in other open mayas on the network.

It sounds like the RESTful interface would serve a very specific purpose as opposed to a more open solution.

my 2cents

Marcus Ottosson

unread,
Nov 3, 2014, 1:13:47 PM11/3/14
to python_in...@googlegroups.com

I remember long ago, i maya there where an web interface, where you could pass commands from the
web browser, cant remember well, but was something like mel:// and your command.

That’s interesting! Looks like it’s still going.

Haven’t heard nor tried that, but I’ll have to give it a go.

Is there any easy - open source -tool to do those “screen captures turned into gif” you usually post?

I’m sure Google would have a better answer for you, but if you ain’t got Photoshop to do Save for Web.. then there’s also FFMpeg that can supposedly do similar things; although from what I gather you’ll need to first convert your videos to images and then to .gif.

I have been using redis for my application communications.

Hi Damon, thanks for sharing.

Redis is a message queue/broker much like ZeroMQ and has similar advantages and disadvantages. One of the reasons not to go with ZeroMQ or Redis is their binary requirements - Redis requiring an externally running server and ZeroMQ requiring binaries especially compiled for Maya; per version of Python.

What is nice is that it allows back and forth communications, not just 1-way.. Makes it so I am not completely stuck with just Maya’s versions of python and Qt. I can even execute commands in other open mayas on the network.

That is quite useful, however the same is true for any type of inter-process communication; including HTTP calls. It’s called brokerless messaging.

To summarize; HTTP communication:

  • Supports bi-directional communication
  • Runs natively in any language that supports HTML; which includes Python, but also JS and C# and so on.

Whereas a message queue requires an initial setup, and in the case of Redis, a central broker.

I may even be so bold as to claim that the only real benefit of an MQ is performance; however as Python is only capable of producing a certain amount of information per second, that benefit may never actually surface. Thoughts?

It sounds like the RESTful interface would serve a very specific purpose as opposed to a more open solution.

I’d love for you to elaborate on this. What does “open” mean, if not standardized HTTP calls following a widely used architectural pattern like REST? And in what way does it strike you as specific?

Thanks again!

Best,
Marcus​

Marcus Ottosson

unread,
Nov 3, 2014, 1:29:23 PM11/3/14
to python_in...@googlegroups.com

Runs natively in any language that supports HTML

Sorry, I meant HTTP.​

Justin Israel

unread,
Nov 3, 2014, 1:31:25 PM11/3/14
to python_in...@googlegroups.com


On Tue, 4 Nov 2014 7:13 AM Marcus Ottosson <konstr...@gmail.com> wrote:

I remember long ago, i maya there where an web interface, where you could pass commands from the
web browser, cant remember well, but was something like mel:// and your command.


That’s interesting! Looks like it’s still going.

http://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/Interface-overview-Install-the-Maya-Web-browser-plugin-htm.html

Haven’t heard nor tried that, but I’ll have to give it a go.

Is there any easy - open source -tool to do those “screen captures turned into gif” you usually post?


I’m sure Google would have a better answer for you, but if you ain’t got Photoshop to do Save for Web.. then there’s also FFMpeg that can supposedly do similar things; although from what I gather you’ll need to first convert your videos to images and then to .gif.

I have been using redis for my application communications.


Hi Damon, thanks for sharing.

Redis is a message queue/broker much like ZeroMQ and has similar advantages and disadvantages. One of the reasons not to go with ZeroMQ or Redis is their binary requirements - Redis requiring an externally running server and ZeroMQ requiring binaries especially compiled for Maya; per version of Python.

Redis is a key-value database. It happens to have messaging added on. It's initial intent is high throughput persistent storage. It also offers a number of data types like sets and maps.

It is also possible to find pure python client libraries for ZeroMQ and Redis.

What is nice is that it allows back and forth communications, not just 1-way.. Makes it so I am not completely stuck with just Maya’s versions of python and Qt. I can even execute commands in other open mayas on the network.


That is quite useful, however the same is true for any type of inter-process communication; including HTTP calls. It’s called brokerless messaging.

To summarize; HTTP communication:

Supports bi-directional communicationRuns natively in any language that supports HTML; which includes Python, but also JS and C# and so on.

bi-directional? Is your httpserver making requests to your httpclient? Usually with http, a client makes a requests and waits for a response.

Whereas a message queue requires an initial setup, and in the case of Redis, a central broker.

Yes. Redis is a database, so it allows for persistent storage, regardless of how fast Maya can consume from it

I may even be so bold as to claim that the only real benefit of an MQ is performance; however as Python is only capable of producing a certain amount of information per second, that benefit may never actually surface. Thoughts?

Durability.
Also I don't know what your bold claims are based on. Do you have anything to back up your claim that python cannot produce enough data to see any benefit from a TCP or Unix sockets connection, vs an httpinterface?

It sounds like the RESTful interface would serve a very specific purpose as opposed to a more open solution.


I’d love for you to elaborate on this. What does “open” mean, if not standardized HTTP calls following a widely used architectural pattern like REST? And in what way does it strike you as specific?


What I think is being said here, is the same as what I was stating. While someone may have a specific use case to expose a Restful interface for their application, I don't think it would be as useful to have a completely generic restful implementation of the Maya commands api. It sounds like you were asking if anyone would find that useful. But if you are asking if Restful interfaces into application are useful, then yes.


Thanks again!

Best,
Marcus​

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA6Lde7ce63zRxLdfF%2BV3O9rfAMnoxmA%3D2Bt65pvuCJ8g%40mail.gmail.com.

damon shelton

unread,
Nov 3, 2014, 1:46:46 PM11/3/14
to python_in...@googlegroups.com

Yes, Justin stated what I was trying to say and got my responses out before I could, lol
It sounds very focused on implementation just for Maya's api. I am not stating that isn't useful but could be more useful to put in effort for a system designed around a pipeline that doesn't just involve Maya. Maybe this could be a starting point for a bigger framework. I know this is a group based around python for "Maya" but I rarely have a day in years where I didn't have to involve several other programs, be it at work or my home set of tools.

I am not trying to down your efforts, just responding to your question of whether I personally would have interest in it and my answer is yes, but not just a set focused entirely on Maya.

Marcus Ottosson

unread,
Nov 3, 2014, 1:50:50 PM11/3/14
to python_in...@googlegroups.com

bi-directional? Is your http/server making requests to your http/client? Usually with http, a client makes a requests and waits for a response.

Mhm. The client can also be a server. That way, they both expose interfaces towards each other that they call upon.

It is also possible to find pure python client libraries for ZeroMQ and Redis.

For ZeroMQ, that would be amazing. For Redis, I think you would still need the binary server. Could you share a link for the pure-python ZMQ? Thanks!

Do you have anything to back up your claim that python cannot produce enough data to see any benefit from a TCP or Unix sockets connection, vs an httpinterface?

I take it back!

I don’t think it would be as useful to have a completely generic restful implementation of the Maya commands api

I imagined the interface to lean more towards a general access to Maya; like modifying, creating and deleting nodes, regardless of which API is being used from within Maya - be it maya.cmds or OpenMaya.

But if you are asking if Restful interfaces into application are useful, then yes.

Specifically, a Restful interface into Maya.

Given that it doesn’t look like a popular idea (!) let me elaborate a little further. At the moment, I could share a tool with you that uses PyMEL. Because it uses PyMEL, it’ll work on my version of Maya, but also yours, and everyone elses. The tool is distributable and standalone.

Now, imagine that I built a tool that doesn’t uses maya.cmds, but also ZeroMQ or Redis. For you to use now, you’ll need these libraries too. In the case of Redis, I’d have to ask you to also install a central broker somewhere and configure it, and in the case of ZMQ, I’d ask you to do some compiling.

What I’d imagine for something like RestMEL is for a similar integration as PyMEL, making tools built externally distributable and standalone.



For more options, visit https://groups.google.com/d/optout.



--
Marcus Ottosson
konstr...@gmail.com

Marcus Ottosson

unread,
Nov 3, 2014, 1:52:22 PM11/3/14
to python_in...@googlegroups.com

but not just a set focused entirely on Maya.

The coupling with Maya would be similar to that of maya.cmds. It’s a means for accessing Maya from within Maya. RestMEL would be the very same, but for access from the outside.

In that way, it may make for a better companion in integration with other application, if you do in fact design software to run externally. Rather than utilising maya.cmds or PyMEL, your Maya integrations would use RestMEL.

--
Marcus Ottosson
konstr...@gmail.com

Justin Israel

unread,
Nov 3, 2014, 2:26:09 PM11/3/14
to python_in...@googlegroups.com
On Tue Nov 04 2014 at 7:50:48 AM Marcus Ottosson <konstr...@gmail.com> wrote:

bi-directional? Is your http/server making requests to your http/client? Usually with http, a client makes a requests and waits for a response.

Mhm. The client can also be a server. That way, they both expose interfaces towards each other that they call upon.

That is just two connections, bound on each side with different ports. Not bi-directional communication.  

It is also possible to find pure python client libraries for ZeroMQ and Redis.

For ZeroMQ, that would be amazing. For Redis, I think you would still need the binary server. Could you share a link for the pure-python ZMQ? Thanks!

redis-py appears to be pure python
zmqproto appears to be pure python 

I havent researched either of these. The only point is that the protocol can be implemented in a pure python solution.

Do you have anything to back up your claim that python cannot produce enough data to see any benefit from a TCP or Unix sockets connection, vs an httpinterface?

I take it back!

I don’t think it would be as useful to have a completely generic restful implementation of the Maya commands api

I imagined the interface to lean more towards a general access to Maya; like modifying, creating and deleting nodes, regardless of which API is being used from within Maya - be it maya.cmds or OpenMaya.

But if you are asking if Restful interfaces into application are useful, then yes.

Specifically, a Restful interface into Maya.

Given that it doesn’t look like a popular idea (!) let me elaborate a little further. At the moment, I could share a tool with you that uses PyMEL. Because it uses PyMEL, it’ll work on my version of Maya, but also yours, and everyone elses. The tool is distributable and standalone.

Now, imagine that I built a tool that doesn’t uses maya.cmds, but also ZeroMQ or Redis. For you to use now, you’ll need these libraries too. In the case of Redis, I’d have to ask you to also install a central broker somewhere and configure it, and in the case of ZMQ, I’d ask you to do some compiling.

Well you might ask for someone to install Qt5 if you are delivering a qml app. Or you might ask them to install flask. It may or may not be something that can be bundled either way. 
It really depends on the types of tools you are distributing. At least a commandPort is integrated to Maya. You still have to ask someone to run your server code from Maya to expose an http interface. All of this is really abstract anyways as it may or may not be a pain for some people. I normally wouldn't think to try and distribute a tiny little dialog tool that has a big dependency on redis. But I might decide to do that if I am releasing a really big application. If I had a use case for needing ZeroMQ, I might require that as a dependency. If my application does just fine with an http interface, then that works as well. 

What I’d imagine for something like RestMEL is for a similar integration as PyMEL, making tools built externally distributable and standalone.

I still wonder if it would cover the same bases to just have a simple http interface that accepts a predefined json structure and dynamically executes your commands, instead of mapping all of the routes to cover the entire api.
 

Marcus Ottosson

unread,
Nov 3, 2014, 3:57:10 PM11/3/14
to python_in...@googlegroups.com

That is just two connections, bound on each side with different ports. Not bi-directional communication.

What I meant was, the tool can talk to Maya, and Maya can talk to the tool, with both a message queue and HTTP requests.

I havent researched either of these.

Did you just google those? :)

I still wonder if it would cover the same bases to just have a simple http interface that accepts a predefined json structure and dynamically executes your commands, instead of mapping all of the routes to cover the entire api.

That is true.

Now with the disadvantages at bay, what advantages, if any, can be found?

Best,
Marcus



For more options, visit https://groups.google.com/d/optout.



--
Marcus Ottosson
konstr...@gmail.com

Ravi Jagannadhan

unread,
Nov 3, 2014, 4:03:05 PM11/3/14
to python_in...@googlegroups.com
I am very late to this discussion, so my apologies if this has already been covered by you smart folks. Have you tried using Twisted? I encountered it here:

http://www.raywenderlich.com/3932/networking-tutorial-for-ios-how-to-create-a-socket-based-iphone-app-and-server

when I was mucking about writing something to pass info from Maya to an iPad.

Ravi


For more options, visit https://groups.google.com/d/optout.



--
Where we have strong emotions, we're liable to fool ourselves - Carl Sagan

Justin Israel

unread,
Nov 3, 2014, 4:22:09 PM11/3/14
to python_in...@googlegroups.com
On Tue, Nov 4, 2014 at 9:57 AM, Marcus Ottosson <konstr...@gmail.com> wrote:

That is just two connections, bound on each side with different ports. Not bi-directional communication.

What I meant was, the tool can talk to Maya, and Maya can talk to the tool, with both a message queue and HTTP requests.

I havent researched either of these.

Did you just google those? :)


Yes I did. Like I said, I did not research them. My only point was that your argument that they required compiled extensions wasn't exactly true. Pure python implementations are possible and exist. 
 

I still wonder if it would cover the same bases to just have a simple http interface that accepts a predefined json structure and dynamically executes your commands, instead of mapping all of the routes to cover the entire api.

That is true.

Now with the disadvantages at bay, what advantages, if any, can be found?

If someone doesn't want to use the commandPort, or wants to do what they would do through the commandPort, but from a web page. 
 

Marcus Ottosson

unread,
Nov 5, 2014, 8:34:19 AM11/5/14
to python_in...@googlegroups.com

Have you tried using Twisted?

This is probably a little off-topic, as it is my understanding that Twisted merely offers an event loop and even though it’s intended for interprocess communication (read “web”) it doesn’t actually offer any of that on it’s own but is instead used together with other solutions, such as websockets like in the case of the article you posted.

Here’s another question.

For communicating with Maya externally, is anyone using the commandPort? Why not?



For more options, visit https://groups.google.com/d/optout.



--
Marcus Ottosson
konstr...@gmail.com

Justin Israel

unread,
Nov 5, 2014, 1:25:14 PM11/5/14
to python_in...@googlegroups.com


On Thu, 6 Nov 2014 2:34 AM Marcus Ottosson <konstr...@gmail.com> wrote:

Have you tried using Twisted?


This is probably a little off-topic, as it is my understanding that Twisted merely offers an event loop and even though it’s intended for interprocess communication (read “web”) it doesn’t actually offer any of that on it’s own but is instead used together with other solutions, such as websockets like in the case of the article you posted.


It's basically an asynchronous framework. So it provides solutions for doing the equivalent of what you might use threads or multiprocessing for in your app, as well as offering "twisted compatible" communication modules like sockets and web stuffs. Big paradigm shift to deal with, and a pain if you have never used it but you have to maintain someone's code that does use it.  :-)


Here’s another question.

For communicating with Maya externally, is anyone using the commandPort? Why not?


My MayaSublime plugin relies on the commandPort.



--

Marcus Ottosson
konstr...@gmail.com

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOB7RH36t3hYaLhD%3D5eqtkL3O6CPfPijajzozT8NiDR59Q%40mail.gmail.com.

Marcus Ottosson

unread,
Nov 9, 2014, 10:19:44 AM11/9/14
to python_in...@googlegroups.com

Thanks for this!

As it turns out, commandPort is very capable of most of RestMEL’s intended functionality, apart from an apparent security issue of exposing each Maya session to arbitrary and potentially harmful commands being executed; e.g. subprocess.call(["rm", "-r" "/"]), however security is possibly not an important-enough issue for it to be considered when choosing between something like RestMEL and a custom implementation.

More discussion here: http://forums.cgsociety.org/showthread.php?p=7927900
Summary here: https://github.com/abstractfactory/RestMEL/wiki

As such, there will be no further developments of RestMEL.

Best,
Marcus



For more options, visit https://groups.google.com/d/optout.



--
Marcus Ottosson
konstr...@gmail.com

Marcus Ottosson

unread,
Nov 9, 2014, 10:21:28 AM11/9/14
to python_in...@googlegroups.com

About the security issue, reference here:

Care should be taken regarding INET domain sockets as no user identification, or authorization is required to connect to a given socket, and all commands (including “system(…)”) are allowed and executed with the user id and permissions of the Maya user. The prefix flag can be used to reduce this security risk, as only the prefix command is executed. - http://help.autodesk.com/cloudhelp/2015/ENU/Maya-Tech-Docs/CommandsPython/commandPort.html

--
Marcus Ottosson
konstr...@gmail.com

Michal Doniec

unread,
Nov 21, 2014, 11:54:08 AM11/21/14
to python_in...@googlegroups.com
No such thing as pure python redis. It would be extremely slow. Redis-py is just a library which allows to talk to redis server from python. Redis is also gimped under windows.



Justin Israel

unread,
Nov 21, 2014, 3:14:51 PM11/21/14
to python_in...@googlegroups.com
Michal, I think you misread the previous posts regarding Redis. No one had suggested a pure python implementation of the Redis server. The question was about a pure python client, which as far as I can tell redis-py satisfies. It is a pure python client which would make it easier to use from something like Maya, where you don't need any compiled extensions. 

I very much agree with you that a pure python Redis server would be slow :-)


On Sat Nov 22 2014 at 8:47:38 AM Michal Doniec <don...@gmail.com> wrote:
No such thing as pure python redis. It would be extremely slow. Redis-py is just a library which allows to talk to redis server from python. Redis is also gimped under windows.



--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages