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
>
>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
>>>>
>>>>
>>>
>>>
>>
>
