When we switched to using toolkit and toolkit apps for our production entirely, we’ve noted that without internet connection the production is almost entirely handicapped since most things toolkit related require calls to the (external) service. Since internet outage rarely happens this was not a major concern at the time but I’m looking at it a bit differently now.
Yesterday, we had an outage of around 2 hours and the thing is, if at least tk-multi-workfiles2 worked for simple opening and saving of the workfiles the production could have managed to roll on for that period.
I’m wandering about two things:
could it be that we somehow introduced a dependency on the connection ourselves (through the hooks or something) and the expected behavior should be that the app works even without the internet (even if hindered in some way),
and if this is not the case, did anyone tackle this problem in the past, perhaps?
Couldn’t find much searching the forums and support portal, frankly, but i could have missed something… In any case, I’d appreciate some input since I’m struggling to think where to start if we were to try and mitigate this problem in any way ourselves.
Hello – we do have some solutions for studios that want to work offline, but these still require access to your Shotgun site. The presumed audience there isn’t really regular users who have occasional outages, but rather clients who are fully “locked down” and have their shotgun site installed on their own local servers.
With Workfiles, it needs to access Shotgun to build the task hierarchy in the File Open dialog, and if you create any folders, it needs to update the path cache. You also need to have an active, authenticated Shotgun session in order to bootstrap Toolkit.
In a pinch, your best bet would be to use the DCC’s native File Open/File Save, then ensure that artist work is saved to the correct file location once your connection is back up.
Thank you for your input. Yeah, I guess I’m asking for something that would not be quite in line with the architecture of toolkit itself.
Unfortunately, the proposed solution is not… well… elegant, so to speak. As pipeline TDs we invest quite a bit of effort to teach artists specifically NOT to use native Open/Save mechanisms and are trying to pull them out of “file system digging” altogether. Once that is achieved, on a rare occasion when they do need to go that route, we can’t expect them to be necessarily well prepared/trained to do so…
That’s not to say I’m dismissing the idea since it’s viable, of course.
Perhaps with quite a bit of effort and custom development something can be cobbled up - I’m thinking a replacement tool for Workfiles (with same/similar UI) which reads local pathcache and last cached config schema and only allows opening of existing workfiles and saving them incrementally, but does not depend on shotgun/toolkit in any other way… Not sure I’m taking everything into account. Sounds plausible. On a massive scale even worthwhile. Needs more thought.
The trouble is, that Toolkit in general needs access to your Shotgun site. Anything using the core API may trigger it to reach out to Shotgun. It would be a very big reworking I think.