I am not familure with how the indexing interplays with the rest of the Jena system. My assumption is, like you, that we only want the ETag in the Fuseki layer. However, to generate an ETag it seems like Fuseki will need to be able to ask the underlying dataset when the last change occured, but then you also want to know if indexing has changed so that results my be changed as well.
If we consider ETag generation separate from the Dataset then the ETag generator could register as a listener to the dataset and react whenever a change occurs to the model. This doesn't solve the problem of responding to index updates. However, whatever interface the listener uses to trigger an ETag change could just as well be done by an indexer. Is there an indexer listener interface (ala Model/Graph listeners)? In this solution the ETag gets input from any registered component. I think that each registered component should have a "name" and a "value". The ETag generator would retain the most recent value for each registered component and generate a new ETag when a value changes. So I see a class with 2 methods void ETagGenerator.change( String name, String value ) and String ETagGenerator.getTag(); // to retrieve the current tag. Claude On Mon, Jun 29, 2015 at 2:50 PM, [email protected] <[email protected]> wrote: > 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 > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
