On Sun, Sep 4, 2016 at 8:23 AM Justin Israel <[email protected]> wrote:
> > > On Sun, 4 Sep 2016, 12:20 AM Marcus Ottosson <[email protected]> > wrote: > >> > 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. >> >> I'm surprised you said this. :( I would have expected you to care about >> your software cleaning up after itself. >> > > I don't understand this comment. Why are you implying that my software is > not cleaning up after itself? What is the difference between Maya posting > to a udp port and it buffering data in memory that someone isn't > collecting? Udp should be quite low impact. It's no different than if we > told Maya to write the script editor to a file that someone either tailed > or didn't. Or if a plugin emits it's log output to some logging endpoint. > > I do have the ability to stop the publisher when Sublime shuts down. But > only in ST3 because they give you a plugin unload hook. That is already > added to MayaSublime. > > The only way I can really see to get Maya to stop publishing if Sublime > goes away is to have a heartbeat. If Maya didn't see an updated timestamp > in a period of time, it might disable the publish. But really I would have > to profile and determine that it even matters. I have to believe sending to > udp is faster than having the script editor open and seeing the output > write to that widget. > Just to clarify my response, I acknowledge that you are identifying that the publishing is potentially left running in Maya if sublime crashes or if using ST2 (or if the unload hook doesnt run for some reason). Really I was objecting to me not caring about cleaning up my software. I considered this configuration to be just like a standard Maya plugin situation, where a plugin gets loaded. The user can choose to unload that plugin from Sublime. What I meant by not having to care if the other side disconnects is related to transient disconnects. Like if you restart Sublime. I don't have to constantly deal with re-establishing a TCP connection between Maya and Sublime. > > > >> On 3 September 2016 at 13:04, Justin Israel <[email protected]> >> wrote: >> >>> 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 >>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3woEpCJWcsHTQrXSx8CKsFCz4fyRhHLEFeYk%3D%3DmUxy7g%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/CAFRtmOC2Aikemic-M%3DuS19G1PL0DnwT5w8QJ01x6%2BPUjwjDhtw%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC2Aikemic-M%3DuS19G1PL0DnwT5w8QJ01x6%2BPUjwjDhtw%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/CAPGFgA0HwVGf1%2BXoFNkW%2Bz9eKWsAf7zw7Uh4pp8WY_dCf5gehA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
