In one day we have now gotten 3 PRs to get automated sync between Kitsu and OP!
I wanted to create this thread to let us better communicate on how to move forward and not work over each other.
All 3 does things quite different so I think it’s best to open a communication here so we don’t do a bunch of development in vain.
Here is the 3 PRs:
Leecher Service by @Danell (me): Add leecher service (gazu event listener) by EmberLightVFX · Pull Request #25 · ynput/ayon-kitsu · GitHub
Ayon-Kitsu + Auto-Sync by Ahmed Gamal : Ayon-Kitsu + Auto-Sync by Agamal17 · Pull Request #26 · ynput/ayon-kitsu · GitHub
Create, Update and Delete of folders and tasks by @scott_mcdonnell_jam: Enhancement/delete kitsu entities by scottmcdonnell · Pull Request #28 · ynput/ayon-kitsu · GitHub
From my understanding, these are how each PR does the syncing. If I have misunderstood anything, please correct me:
Leecher Service adds a new kitsu service called Leecher. The Leecher service handles all the gazu listening and creates an Ayon event when catching something.
The event is then picked up by the Processor service and passes it over to the correct handler that creates everything for both Ayon and Kitsu as needed. This means we can add more custom events and handlers in the future if needed. It also means we will have a two-way communication between Kitsu and Ayon.
It’s 100% inspired on how the Shotgrid and Ftrack services work. If the Processor service would go down or get updated the Leecher will still fetch all events and queue them up for when Processor gets up and running again.
The services uses Gazu API for Kitsu communication and ayon_api + ayon entities for Ayon communication
Currently there is no update with the UI but in the end the user will be able to select what projects to sync, or sync all open projects from Kitsu
Ayon-Kitsu + Auto-Sync removes all frontend and instead adds the gazu event listener. When something gets added, updated or removed a full sync happens. The sync-code is the same as the old full_sync that uses zou API instead of the gazu API to fetch data from Kitsu and uses postgres commands to modify the Ayon code.
Create, Update and Delete of folders and tasks adds a bunch of pytests to test all possible syncing. It also splits out the full_sync into individual functions for assets, episodes, sequences, shots and tasks. It communicates to Ayon over ayon_api.post.
My thoughts on each PR:
Ayon-Kitsu + Auto-Sync updates the current code quick and dirty to add automatic synchronization. It does one thing and it does what it’s suppose to do and not much more.
Create, Update and Delete of folders and tasks gives us a bit more flexibility compared with the current full_sync code. Here each event gets its own function that handles the sync. It makes it easier to implement future features from Kitsu.
Both of these uses the Processor service to directly use server code to modify Ayon. There is no two-way communication.
Leecher Service is based on how the Shotgrid and Ftrack addon is built. The code is more split up compared with the other two PRs and allows for great flexibility in the future. It also only uses the services to code to communicate with Kitsu and Ayon and doesn’t touch the server code at all.
Leecher Service would be the best way forward as its built exactly how the Shotgrid and Ftrack addons are built. It will give us a two-way communication. Any update to Ayon that might change how the Shotgrid and Ftrack addons work will easy be added to the Kitsu addon. The use of handlers opens up special edge-cases where external tools can modify both Kitsu and Ayon at the same time.
Create, Update and Delete of folders and tasks gives us great pytest-functionality and I would love to have that in the final product so we super quick can test any future development. (Currently I have setup a mouse-auto-clicker that creates new projects, tasks, comments etc for my tests lol).
I would love to hear both from Ahmed Gamal and @scott_mcdonnell_jam l but also Ynput themself on your thougts for moving forward with the Kitsu sync integration.