Autofetch is still operating. But whilst not deprecated, it has been supplemented via fetch(urlStr,headersDict,attrNameStr,cmdStr[,httpMethod,POSTbody]). although the later has more complex retrieval+transformation in mind, I think it might be a more sensible choice. Not least, as an action operator it may be called on demand (even in basic Autofetch-like configuration), unlike the older Autofetch.
A point to consider in this is the effect of the fetched notes. I’m not sure to degree-if at all—that having notes like prototyped or templates having their $Text as fetched content. On the face of it, if items are only fetch once a session at start on on demand for files known o have changed, this likely may work, but its likely this exact usage hasn’t been tested (because the idea ha not come up before)
Code, especially code running in the app (e.g. not just on-demand for export), needs more careful consideration as the code may be dependent upon document structure, prototypes, user attributes, boilerplate code, etc. what either doesn’t exist or should differ from the installed form. Otherwise, the risk is we saw off the very branch upon which we are sitting. Unintentional hilarity ensues …
An unspoken constraint worth surfacing here is if the team is worldwide. In the same timezone, we can call or walk to their office. But, if other team members are fast asleep during our daytime that is not an option. This is not everyone’s constraint but a real factor for some teams.
(Action code) installer libraries could be called used—the community has made some, indeed possibly even called by fetch(). But it is a lot of extra work to make and risks (installer design errors) adding new errors. So far such installers are mainly a one-use-and-done tool to pre-configure new TBXs with non-trivial set-up (or simply consistency over many such new documents) rather than a a constant update mechanism.
Something we all say, but often do not actually exercise, is to only do code/prototype/template development in files designed for that. No code dev in live content files. Tends not to happens as it ends up as delay and for most users the dev and end user are the same person. But such formalism may help here. If doing non-trivial Tinderbox design work (other than adding content) then working on a ‘minimal viable example’ document is significantly easier, especially if odd gremlins are proving have to flush. This he specimen content is reflective of the whole , then only safe, tested, code adds to/replaces code in the working docs along with necessary accommodations like adding new attributes or altering an attribute’s data type.
There are two parallel strands here: multiple documents needing consistent code vs. multiple users employing code consistently.
Action code now allows inline code comments.
Bottom line, there is no simple answer. Al these are necessary kludges as the app is a single user desktop app but we want to use it as a multi-user/concurrent version system and the two are not a natural map. In such circumstances, as in operational work, pragmatism helps: “What can I safely/practically do?” trumps “What I want to do?”. The former always nudges us towards the objective. The latter has us constantly checking why we aren’t where we wish to be.