...
Please squash a bug!
Expand Jira server DuraSpace JIRA jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets resolved this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets created this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Minutes
1. Discussed
| Jira | ||||||
|---|---|---|---|---|---|---|
|
2. Memento is a popular and widely-supported specification for versioning, many LDP platforms are choice Memento. Thus, we try to adapt Memento into Fedora's HTTP API for versioning. People in the meeting all agreed to proceed it. @A. Soroka will send out messages to the fedora communities.
3. Cleaning up the fcrepo-kernel-api, including moving JCR and modeshape (been done). After removing JCR, any implementation of the Fedora does not have to know about the JCR. There is on open request https://github.com/fcrepo4/fcrepo4/pull/968 . This PR pushed JCR Session into the HTTP layers. You still need to address JCR Session in the HTTP layers. This is the intermediate implementation before completely removing JCR out of fcrepo-kernel-api.
Still need to discuss and clarify the definition and usages about the "transaction" in Fedora. e.g. @mike Would it make sense to call our new session construct a "transaction", since that's essentially what it is?
or if we use different backend which does not support transaction (e.g. hadoop)? An idea is to provide an optional for users to chose transaction or not., or an API-X module. Need to know how the communities think about it. (e.g. islandora community)