There is no case of external modification of the database which Fuseki
is running. A disaster will occur otherwise. [Modifying externally
while running requires a different approach (e.g. switching between two
copies of the database ... maybe ... so many ways to corrupt a database
... ).]
E-tags is a quite technical solution - will any system actually use it
for real even if it is the right solution? We wouldn't want to find out
that etags support does not get used. For the SPARQL Protocols case
(with query stings), it might not really get used. Has caching of
requests including query string rolled out to any degree? (a point from
discussion in JENA-388).
If query string currently cause no caching by intermediaries in
practice, will clients cache which is the case of one client reissuing
the same query? Possible but is it likely?
See also JENA-626 "SPARQL Query Caching". That would make a difference
- different client apps starting up often ask the same query to get started.
Andy
On 29/06/15 16:03, Claude Warren wrote:
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
