There is now a couple of DCC’s that’s using websockets to communicate with Ayon like tvpaint, after effects, etc. I would like to modify the Fusion integration to do the same as the current way is prone to misshaps.
From what I can see all implementations uses the same base for its communication but it’s implemented per addon.
Is this something that should be moved over to ayon_core so it’s easier to setup a socker communicator and without duplicating code all over the place?
Is it something in the works or something that might happen in the future?
Mostly wondering if I should wait working on the new Fusion integration or if I should duplicate the code from say tvpaint and start working.
That PR as far as I can see actually intends to ‘duplicate’ even more in preparation of moving to separate addons. I feel like it’s kind of showing the exact opposite trend of what @Danell tried to get to here - which is “re-use more code” instead of duplicating code across different code repositories.
tbh, I imagined the idea discussed in the post as some sort of adding a new interface to ayon addon interfaces.
That’s so cool! Almost identical speaking of some methods.
I’ll try to write down my thoughts about the code duplication. Initial information: we’ll be splitting all the host integrations into separate addons (== separate repositories), the same with modules, and current applications.py will become applications addon.
Ad the scripts PR I’ve duplicated prelaunch hook and launch script, not the communication logic. Without the PR, ayon-core would have to know about the other addon inner implementation, which is not great, and the addons are dependent on logic in core. Even though some code is the same and can be reused now, does not mean it can be reused in future. Also conditions like “if host is photoshop then import function A from module B and call it with these arguments” should not be in core addon at all, core addon should not be that specific.
Change in the communication logic, would require to be tested across all other addons. And change for single addon may also make the other addons incompatible, thus they’d need to release new version because of that. That lowers dynamic compatibility of addons.
Now about the backend of the communications logic, which is actually the topic. Let’s consider we have at this moment Harmony, TVPaint and adobe hosts Photoshop & AE (because they have almost identical communication logic). If you look at their backend communication implementation, you’ll find out they are not that same. Classes and functions may look same, but are not exactly the same. Harmony is using sockets, adobe is using some aiohttp module and tvpaint is using different aiohttp module. I’m not sure if that can be abstracted into single implementation that could be used across all of them, but I don’t think it would be that easy.
At this moment it is easier, faster and safer to just duplicate it, knowing the host integration into DCC is not dependent of specific version of ayon-core.
If you would have time to implement communication logic that would be integration agnostic and reusable for more than 2 hosts, without any host specific logic in it, then we can add it to core and change the addons to use it.
Hit me if you have different opinion.
2 Likes
