On Jun 29, 2015, at 9:33 AM, Claude Warren <[email protected]> wrote:
> If there were an ETag per dataset and a method on the dataset to force an
> ETag reset would this address the index issue in that the indexer could reset
> the ETag when it deemed appropriate?
It might-- for that indexer. I would be concerned about setups in which another
process acted against the data "out of sight" of Fuseki. But would the ETag be
on ARQ's Dataset itself? If I understand what's going on here correctly
(debatable at best), Dataset should not have any HTTP concerns mixed into it.
ETag would be on something closer to Fuseki's DataService, which I do not think
would normally be accessible to an indexer which is only aware of what's on
disk… but this is all from my understanding of the architecture, which is
pretty minimal. {grin} Maybe some kind of "last changed" timestamp could
reasonably go on Dataset to support this kind of function?
> In any case I would go with the first choice.
It definitely seems like the most bang for the least buck.
> Is there anything that prohibits sending both an ETag and a constant expires?
> I havn't looked but I recall they are not mutually exclusive.
Yes, I think you are correct. I suppose a bad ETag will never be known to be
such as long as it is "inside" the range of a still-good Expires, but that is a
question for the administrator configuring Fuseki, it seems to me. There is
also Cache-Control, of course, in the same field of functionality.
---
A. Soroka
The University of Virginia Library
