As it was mentioned in previous sections, there are basically two kinds of reload strategies in Ressor - polling and listening. Here is a table of support:
Below are the special notes, specific to each data source.
You can just subscribe to the changes by:
Since OS capabilities are used for that, please check that your underlying File System support change events.
Since it's very resource-consuming to reload all the data every time just to check that it was changed, there are several Http Header-based approaches, represented by the
Ressor will use ETag header as a version snapshot of the resource. It will send the If-None-Match header with the last version value in order to receive only the modified body. Check how it works here.
Ressor will use Last-Modified header as a version snapshot of the resource. It will send the If-Modified-Since header with the last version value in order to receive only the modified body. Check how it works here.
Same as ETAG, but for servers which doesn't support If-None-Match header. Must support HEAD requests.
Same as IF-MODIFIED-SINCE, but for servers which doesn't support If-Modified-Since header. Must support HEAD requests.
Always reload the resource on poll.
Whether you use the local repository or ask to clone remote one for you, Ressor does only single mutation action to the underlying repository:
git fetch, which downloads all the latest changes from remotes.
No checkout, pull, merge, etc. happens with respect to repository. Bare repositories are recommended and supported.
The behavior of S3 source implementation is similar to Http one, but since the support of versioning by AWS is something guaranteed, it doesn't provide with opportunity to select any strategy.
It will use
If-None-Match approach when applicable (should be in most cases), otherwise switch to
If-Modified-Since. This is completely transparent to the end user.