Fix ETag handling for Binaries and Binary descriptions

[acoburn]

Resolves: https://jira.duraspace.org/browse/FCREPO-1983
Resolves: https://jira.duraspace.org/browse/FCREPO-1754

This is an alternate resolution of this issue. See #1022 for a different approach.

The advantage of this PR (from my perspective) is that ETag and last-mod values on the fedora:Binary and associated description are decoupled.

Note: this PR also addresses the Strong/Weak ETag issue: Binaries produce strong ETags, everything else produces a weak ETag. So it also supersedes #991

See: http://irclogs.fcrepo.org/2016-04-18.html for further discussion of this.

Based on discussion, this approach is to be pursued instead of #1022

[awoods]

To be clear, this current PR bases the:

• etag and last-mod for NonRdfSources on the Description, and
• etag and last-mod for Descriptions on the NonRdfSources.

A brief rationale would be helpful here.

[acoburn]

@awoods I agree a rationale would be helpful here. Would you like that as an inline comment or written here in the github comments? In brief, though, it follows from the principle of the binary being the subject of the triples in the description.

[acoburn]

@awoods as a side note, this is exactly why we need a specification. It is impossible to fix incorrect behavior if there is no clear document describing what correct behavior is.

[awoods]

Maybe an inline comment would help folks who look at the code in the future understand what is going on.

[ajs6f]

Six kinds of amen.

On Monday, April 18, 2016, Aaron Coburn notifications@github.com wrote:

@awoods https://github.com/awoods as a side note, this is exactly why
we need a specification. It is impossible to fix incorrect behavior if
there is no clear document describing what correct behavior is.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1024 (comment)

[ajs6f]

To be clear, my comment was in support of @acoburn's remark about specification.

[sprater]

@acoburn: I pulled your fix into my fork, compiled, and tested in the web UI again the case I documented in FCREPO-1983. That problem appears to be fixed.

[acoburn]

@sprater thanks for checking! I would like to add some additional integration tests before this is actually merged. If that happens next week (before the 4.5.1 release), I'll close this PR and re-target it at the DEV branch; otherwise, it will stay where it is. In any case, this ticket is certainly moving forward.

[sprater]

@acoburn sounds good. I'll wait for the merge when it occurs, then test again, just to make sure.

[acoburn]

Superseded by #1028