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