jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: strong etags in simple webdav server
Date Thu, 14 Jul 2005 08:15:50 GMT
hi brian

apparently your initial mail got lost. sorry for that.

i'm not sure, whether it would be correct to build a
non-weak etag with the information present. specially
with the current situation where neither resources on
top of the import/export commands have an influence on
the 'quality' of relavant data provided by the
interchangeable export-commands.

second i don't remember, why we have that 'getStrongETag'.
that does not make sense to me any more and i would
rather want to remove it.

so... could we
- delegate the calculation of the etag to the
   commands, letting them decide on whether they are able
   to provide any and whether it would be a strong or a
   weak one?
- remove that additional method in NodeResource that is
   not used?

please correct me, if i'm missing something.

regards
angela


> Brian Moseley wrote:
> 
>> what would it take to support strong etags in the simple webdav server?
>>
>> if i understand strong etags correctly, the etag must change any time 
>> the response headers or resource properties change.
>>
>> the only response headers that appear likely to change are 
>> content-length, content-type and last-modified. two of those three are 
>> already accounted for in the weak etag.
>>
>> for resources that have a jcr:lastModified property (as those imported 
>> with FileImportCommand will) that is updated when properties change 
>> (which obviously isn't the case now, since PROPPATCH is not 
>> implemented), it does not seem like anything extra would need to be 
>> done to account for changed properties.
>>
>> what about resources imported with XMLImportCommand? since they aren't 
>> required to have a last modified property, will the last modified 
>> property always be represented as the current time?
>>
>> what about versioned resources? is jcr:lastModified sufficient, or 
>> would the current version's uuid or some other value need to be added 
>> to the strong etag?
>>
>> have i missed anything important?
>>
> 


Mime
View raw message