Not sure if anyone actually understood my workaround: please watch this video.
The reason I’m suggesting this is an official method with a button that would clear cache is because some web services also cache assets stored in them for faster loading.
Allowing end users to disable cache would only lead to users disabling cache because no one would know any better: which would only result to wasting bandwidth resources on content creator’s hosting servers.
Technically this feature would be an button to do unwitting DoS attack via bandwidth decay. **Ofcourse servers have safe-guards to prevent this: but it could leave to content simply not loading for people having cache disabled since their IP address would be blacklisted temporarily. ** and with that complaints.
Bandwidth is still a limiting factor, and can get quite pricy:
Considering I pay quarter of thousand per year for a distributed service with 100 Gb bandwidth (its a service so they make sure that nothing happens so I can stay lazy without having to do too much sysadmin work), it is enough for my purposes and with proper caching workable.
With a potential load from HF, I may have some issues later with my existing hosts, so I am currently looking into investing in some rack space and co-location services instead of ready providers.
Unlimited bandwidth is seriously a lie for server hosts, as it applies only to html pages, not files. With the normal web this is not much of an issue, but once you dealing with much larger files here this issue will popup. You can check any, of the, ToS on Unlimited Servers, and they will always mention in small print that the unlimited bandwidth is within reason…
Say you have a domain with 10-20 assets averaging at 10 mb per asset (including textures and animations): Add a 25 or so unique visitors (unique, as in someone loading for the first time or cleared cache) per day, or have people using some of those assets in their own domains. Eventually will start to have issues after a few weeks, unless there is caching in between. This is also the reason why Model optimization is very critical with models you bring in to high fidelity.
We should be thinking what happens if you scale our current situation upwards and consequences of having the ability to turn off cache
This work around solves also plethora of issues which happen when caching happens on multiple levels. Caching also happens on server side on most high-traffic sites, but this is to save actual cpu processing and page render time.
So instead of thinking of “disabling cache” we should go for a clear cache (that then would reload everything in the domain), and a workaround that is used by Web Developers, to help content creators to update their assets. This way, end users have the ability to check if an issue was related to their cache, instead disabling it completely.
Other method that would rely on the content creator would be to make the BatchLoader check the header of the http request, and check the Cache-Control header (See 14.9 of w3 spec) : if this would be set to no-cache, it wouldnt be cached. This way content creators can be responsible for their own bandwidth use instead of having the end users be responsible for their cache