Thanks for starting to look at this. Replies inline.. On Sat, 3 Sep 2016, 11:40 PM Marcus Ottosson <[email protected]> wrote:
> Based on your description alone, I spot a few potential problems with that > approach. > > 1. What should the sender do when Sublime closes? How will it know that > Sublime closes? Say, for example, that Sublime crashes (spoiler alert, it > can't know). > It won't matter if sublime closes. Maya would publish to udp and no one will receive it so it gets dropped. That was one reason for choosing udp over tcp 2. Second, what should happen if you have multiple Sublime and/or multiple > Maya's? > In the case of multiple sublimes, each one creates a random ephemeral port and tells Maya to use that port when installing the callback. But you bring up a good point because I think I still have a clash that will happen when it saves the callback for removal. I need to namespace the callback by the port number it is given. With multiple Maya's, I am not sure it will be an issue since MayaSublime has to be configured with a port for the target Maya. So extra Maya sessions wouldn't be able to open the same command port. Basically it's only going to talk to the one it is configured to connect with. > I get that you use UDP rather than TCP to avoid having to wait for > confirmation from a potentially dead Sublime, but I'm less sure about how > elegant that actually is. > > Another way might be to instead of pushing updates *to* Sublime, I would > pull *from* Sublime. You could let Maya build up a buffer of messages that > got emptied at a regular (of on demand) basis. That would eliminate the > risk of Maya pushing messages unnecessarily. The buffer could optionally > include a timestamp for each message such that you could pull a particular > range of dates, so as to not prevent others from receiving any, and to not > receive doubles. > > This way worst case scenario is an endless buildup of this buffer internal > to Maya that never gets emptied. To solve that, you could either > periodically empty it from within Maya, or only allow a fixed number of > messages in it. > This actually sounds a lot more complicated than using udp. I didn't only use it for the aspect of not waiting for a response. I also used it because it is connectionless and I don't have to deal with the other side disconnecting on me. Maya just sends output. If sublime is there to pick it up, then it gets displayed. I don't see the need to buffer anything really. Initially before deciding to use udp, I was going to have Maya write to a text file. And then Sublime would read it. But then I wouldn't be able to use select() in case the file gets stored on nfs. And then I would have to just poll it for changes at intervals. Seems udp gives me active feedback as messages arrive. > For multiple concurrent sessions; I'm assuming you deal with this already, > otherwise I've got an idea or two for this as well! > So far I haven't done anything to try to support multiple Maya sessions. I would have to extend MayaSublime to be able to connect to alternate commandPorts. Is that what you meant? -- > 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/CAFRtmOCS_yUK_7tSEaxZCk6wgtadPwScZXoqcVVYnY02pqp7fQ%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCS_yUK_7tSEaxZCk6wgtadPwScZXoqcVVYnY02pqp7fQ%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/CAPGFgA3woEpCJWcsHTQrXSx8CKsFCz4fyRhHLEFeYk%3D%3DmUxy7g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
