H. G. Muller wrote on Wed, Jul 8, 2020 08:01 AM UTC:
The strange thing is that the images Adam uses in the piece section are the same images as that are used in the Diagram. So if after a few days the images in the piece section get flushed at Cloudfare, I would have expected the same to be true for those in the Diagram. I understand that when you would add ?nocache=true (or apparently any dummy CGI arguments), you would bypass Cloudfare, and always get the up-to-date CVP info. But none of Adam's links had that when I looked, neither in the piece section, nor in the Diagram.
As the Diagram constructs the name of the image files by concatenating graphicsDir + colorPrefix + rootName + '.' + graphicsType, the user can force bypassing of Cloudfare by suffixing the graphicsType with ?nocache=true . The images would still be cached in his own browser (as repeated access always uses the same CGI arguments), like any images in the page, but he can flush those himself.
I thought of having the Diagram add the ?nocache=true suffix automatically, but I decided against it. For one, it would be a rare situation that piece images get updated. Normally, when creating a Diagram, one would use existing piece sets on the site, or freshly uploaded membergraphics. Even if an update would take place, it would become effective for everyone in just a few days. And if the usuer is in a hurry, he can add the suffix to the graphicsType himself.
For other images in the original HTML the user must also add the ?nochace=true suffix by hand, if he wants to see updates instantly. E.g. when I publish new Diagrams here, which I usually do for the purpose of testing new features of the betza.js script, I add the ?nocache=true to the link to that script, to make sure I use the just updated version. That older Diagrams elsewhere still keep using older versions of the script doesn't matter, as they did not need the new features, so the older version should be perfectly OK for them. There would be no attempt to load the updated script anyway unless the user explicitly ordered his browser to flush the cash; like image files, separate JavaScript files are also cached by the browser.
Another reason is that I sometimes abuse the Diagram's graphicsDir parameter for specifying a complete URL including CGI arguments, so that the colorPrefix + rootName will be appended as (value of) CGI arguments, for driving a server-side script to generate the piece graphics. An extra ?nocache=true would then violate URL syntax.
The strange thing is that the images Adam uses in the piece section are the same images as that are used in the Diagram. So if after a few days the images in the piece section get flushed at Cloudfare, I would have expected the same to be true for those in the Diagram. I understand that when you would add ?nocache=true (or apparently any dummy CGI arguments), you would bypass Cloudfare, and always get the up-to-date CVP info. But none of Adam's links had that when I looked, neither in the piece section, nor in the Diagram.
As the Diagram constructs the name of the image files by concatenating graphicsDir + colorPrefix + rootName + '.' + graphicsType, the user can force bypassing of Cloudfare by suffixing the graphicsType with ?nocache=true . The images would still be cached in his own browser (as repeated access always uses the same CGI arguments), like any images in the page, but he can flush those himself.
I thought of having the Diagram add the ?nocache=true suffix automatically, but I decided against it. For one, it would be a rare situation that piece images get updated. Normally, when creating a Diagram, one would use existing piece sets on the site, or freshly uploaded membergraphics. Even if an update would take place, it would become effective for everyone in just a few days. And if the usuer is in a hurry, he can add the suffix to the graphicsType himself.
For other images in the original HTML the user must also add the ?nochace=true suffix by hand, if he wants to see updates instantly. E.g. when I publish new Diagrams here, which I usually do for the purpose of testing new features of the betza.js script, I add the ?nocache=true to the link to that script, to make sure I use the just updated version. That older Diagrams elsewhere still keep using older versions of the script doesn't matter, as they did not need the new features, so the older version should be perfectly OK for them. There would be no attempt to load the updated script anyway unless the user explicitly ordered his browser to flush the cash; like image files, separate JavaScript files are also cached by the browser.
Another reason is that I sometimes abuse the Diagram's graphicsDir parameter for specifying a complete URL including CGI arguments, so that the colorPrefix + rootName will be appended as (value of) CGI arguments, for driving a server-side script to generate the piece graphics. An extra ?nocache=true would then violate URL syntax.