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?
