...
- Still time to participate in the Fedora Value Proposition brainstorming
- The Fedora Value Proposition brainstorming exercise will close within the week. Please take a look and add your comments.
Concurrency control options with lack of strong ETags
Background discussion: Strong ETags are desired, but RDF doesn't allow us to make those guarantees. We had planned to use If-Modified-Since: headers, but those have limited granularity of one second. At least one site has a use case for a better solution. Jim Coble said that Duke might depending on the direction that Hydra goes.
LDP standards are heading towards using If-Modified-Since: . We may still need to make better guarantees in Fedora.
There were several proposals about how to deal with this issue:
Use a local header (e.g. X-Fedora-etag:) with weak ETag contents but different semantics
Use higher precision dates in If-Modified-Since. HTTP/1.1 forbids using a different time format.
Solve the problem in clients by having them modify their behavior to strip out the weak identifier.
There was discussion of how stable this option will be. It will work for now, but might break in the future.
ETags allow this behaviour since the only the ID is opaque, not the weakness indicator.
Use properly formatted If-Modified-Since:, but don't have the timestamps reflect actual time, but instead mapped from a better counter.
Clients need to know that they can rely on this, but would not require special processing of the header on the clients.
Fedora would need additional work generate the header. The amount of work required is unknown.
(also mentioned on IRC) HEAD requests could return strong ETags. Clients most often send HEAD requests first. It may not be allowed for HEAD requests to return different headers.
n.b. All of the proposed solutions require clients to be aware of the Fedora specific behavior.
Conclusion:
The LDP spec will change to support the use of If-Modified-Since:. For use cases where that is not good enough, clients can treat weak ETags as strong.
Other options should continue to be explored as needed.
We would like the improve how ETags are generated
Danny will open a ticket about this.
Unknown User (acoburn) will revisit and think about something
Import/Export Sprint Nick Ruest
Starts at 11:00 EDT, Monday, August 29th.
In the first meeting we will talk about Phase one items and assign tasks.
A wiki page for the sprint meeting will be created under the Misc. Meeting section of the wiki.
The goals for the sprint are the Phase one requirements.
The fedora-tech list will be included in discussions, so that those who are not participating in the sprint, but would like to 3. Import/Export Srpint Nick Ruest
Linked Data Notification
Amherst is interested
There is a W3C draft standard
Fedora currently has various ways to do auditing (e.g. built in audit functionality, sending events to an external triple store, storing events as object in the repository).
The complements what already exists in Fedora by standardizing an endpoint for seeing notifications.
Is there interest from Fedora?
Conclusion:
This is in line with LDP and what we are doing. Please review the spec and we will talk more next week.
In-flight tickets
FCREPO-2120 Bethany Seeger will review and close ticket
FCREPO-2111 and FCREPO-2112 Benjamin Armintor would like for someone to take over. There were no volunteers.
FCREPO-2055 Trying to replicate at modeshape level.
FCREPO-2031 Needs re-review
FCREPO-2028 Jared Whiklo has it on TODO list, and should have some time next week. It is mostly maven work.