On 30/06/15 09:48, Rob Vesse wrote:
FWIW dotNetRDF has supported and uses E-Tags when retrieving graphs from
remote URIs since 2010 I.e. for 5 years
So yes these things are used in the real world at least for simple data
retrieval, I haven't honestly ever used them for other SPARQL operations.
We even support caching local copies of remote data based on E-Tags so
that we avoid unnecessary data transfer if the locally cached version is
still the same as the one offered by the server.
Rob
On 29/06/2015 17:33, "aj...@virginia.edu" <aj...@virginia.edu> wrote:
I can only speak for the use cases I actually know about. ETags would get
used, because the most important web app in my concern that is
potentially a client to Fuseki would be able to use them. But that is
just one case.
JENA-626 would be great in any regard.
---
A. Soroka
The University of Virginia Library
Good to know someone would find it useful!
Andy
On Jun 29, 2015, at 12:20 PM, Andy Seaborne <a...@apache.org> wrote:
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, aj...@virginia.edu
<aj...@virginia.edu>
wrote:
On Jun 29, 2015, at 9:33 AM, Claude Warren <cla...@xenei.com> 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
