If you end up wanting to expand to that point of communicating between different systems, you could maybe look at Google Protocol Buffers<https://developers.google.com/protocol-buffers/docs/overview>. It's a serialization format that is structured and can be versioned and validated, so that you can change the format without breaking existing clients using the old format. They are meant for both wire protocols, and for storing your data in a way that you can be sure it can be retrieved even by newer clients down the line. It is language independent, so it doesn't matter if you were communicating between a server written in Java, or C++, or Python, ... I haven't used them directly (my colleagues have), but I use Thrift which is the exact same concept, but also handles all of the RPC functionality for you as well. It was written by someone that went to Facebook and missed Protocol Buffers.
For the part about the Undo stack in a threaded environment, you can mutex guard the undo stack for the entire application, but that still doesn't really guarantee that the undo command from thread A and thread B will be valid unless they too are considerate of the locking. Thread A could start its procedure, maintaining its undo steps, and then get preempted by thread B. Thread B makes some changes to the same area. Then control returns to Thread A, which might have state that doesn't really undo what B might have done. So really it might only work if Thread A has to acquire a lock for its entire operation. This is similar to the reason that Maya makes you defer commands code to the main thread, as it would be really really hard to maintain correct state if multiple threads are changing the graph. I don't know... just brainstorming that one. On Sat, May 17, 2014 at 3:44 AM, Marcus Ottosson <[email protected]>wrote: > It isn't command-line only, but the command-line enforces that commands > maintain plain argument signatures, so I figured it would make a good > example. > > The goal however is to adopt this pattern for gui's and inter-process > communication overall. > > More specifically, I'm looking for a method of executing commands in Maya > et. al. through something like Maya's commandPort. Something fit for a > Service-Oriented Architecture where commands would be advertised remotely > for any give application, such as Maya, and executed within it when being > initially triggered from the outside. But that's another topic. > > > -- > *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/CAFRtmOCjJXcO_4v4Mohd26XsVN17dA5CA7thLOfoQJqjCuePZQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCjJXcO_4v4Mohd26XsVN17dA5CA7thLOfoQJqjCuePZQ%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/CAPGFgA3hZvtZEJ19AER7Bp2DhZe62xWXVVpPGG1frEsPdWSsmw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
