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 On 3 November 2014 19:26, Justin Israel <[email protected]> wrote: > > > On Tue Nov 04 2014 at 7:50:48 AM Marcus Ottosson <[email protected]> > 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 <https://github.com/caedesvvv/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 >> httpinterface? >> >> 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. > > >> >> >> On 3 November 2014 18:31, Justin Israel <[email protected]> wrote: >> >>> >>> On Tue, 4 Nov 2014 7:13 AM Marcus Ottosson <[email protected]> >>> 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 <http://zeromq.org/whitepapers:brokerless>. >>> >>> 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 httpserver making requests to your >>> httpclient? 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 httpinterface? >>> >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA6Lde7ce63zRxLdfF%2BV3O9rfAMnoxmA%3D2Bt65pvuCJ8g%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA6Lde7ce63zRxLdfF%2BV3O9rfAMnoxmA%3D2Bt65pvuCJ8g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1Rqfbtknyw1i6DaJR%2BLBE9RPKmrmSO2P%3Db%3D73aSasfFA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1Rqfbtknyw1i6DaJR%2BLBE9RPKmrmSO2P%3Db%3D73aSasfFA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> *Marcus Ottosson* >> [email protected] >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCGQykA08Bfoyh58ywHoU%2BWTC8nDUfSZ7OkhgUSbNOxTQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCGQykA08Bfoyh58ywHoU%2BWTC8nDUfSZ7OkhgUSbNOxTQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0YzW6JsSaCiJ4hVMufLYHfFyDWFsYZmZEspxjsd%2BOGtw%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0YzW6JsSaCiJ4hVMufLYHfFyDWFsYZmZEspxjsd%2BOGtw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- *Marcus Ottosson* [email protected] -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBo_%3DDDh3%3DGyKz3SR%3D9D8f5LMpdMBFuUm4rxRi%3DgT6b-w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
