...
- Announcements
- David Wilcoxand Andrew Woods are giving a fedora workshop next week in Switzerland at an Islandora training.
- Daniel Lamb talked about the recent Islandora webinar on upcoming release of Islandora 8 and new features.
- Daniel Lamb - went to Drupal Government meeting – Islandora 8 was well received there and some groups plan to use it (Fish and Wildlife for one). Islandora is becoming known in the Drupal community as well. Many Drupal Vendors are aware of what Islandora is and they are starting to use Islandora8. IBM has gotten it to pass all security passes and are going to be using it.
- We do want to move forward with Java 11 - just a matter of when. Andrew Woodssent an email about java out last week, which got stuck in moderation is now sent out: https://groups.google.com/forum/#!topic/fedora-tech/m3wXyarxRJY This serves as the 3 month notice, as specified in our policy.
- idea is to use Java 11 to compile to java 8 byte code and be useable by JVM using java 8 - 11. We should try for this and reconsider if it doesn't work.
- Andrew Woods will explore this to check it out. Starting on 'master' might be a good move, as this might work better without modeshape related code being there.
- Moving https://github.com/pwinckles/ocfl-java-parent into an official Fedora Github repo?
- Bethany Seeger has a concern about tightly coupling a client to fedora creating "fedoraisms"
- Suggestion of having it under the OCFL project - are there any copyright concerns of hosting it there? Probably not.
- Idea then is that it would be published as a separate artifact that we include in Fedora 6
- Maybe Aaron Birkland's go client could be hosted there as well.
- We need to talk to OCFL folks about this idea.
- Fedora would define an interface for how it would communicate to a persistence layer. An adapter would be written to adapt to a particular OCFL client.
- dealing with unversioned content is challenging
- Is there value in showing fedora could work with different OCFL clients? Is something like this important to us (ie: not baking in assumptions about the OCFL client)? There is room in the OCFL spec that are open to interpretation in creation of clients, how would we work with that?
- Fedora could create an interface so that clients can understand/comply with fedora expectations.
- We will continue this conversation in an hour (for those that can)
- Organizing a Fedora documentation review
- Should we organize a doc review? It can involve other folks in the community.
- Go through pages, see what works, make a list of necessary changes and things found not to be working.
- Can be a short sprint. David Wilcoxwill work on pulling this together.
- Unversioned Content
- Peter and BenC agree that unversioned content is out of scope for a generic OCFL client
- Jared - Unversioned content may not make sense in a preservation repository
- is having lots of OCFL versions actually a performance issue?
- At FedoraVABeach, created object with a few thousand objects, created a few versions. Started to take seconds to persist.
- Size of manifest increases proportionally with the size of the OCFL object
- Not likely to have this issue in BenC's use case, only likely to have 10 files in objects, not many changes
- There should likely be a backend for people not interested in OCFL
- is having lots of OCFL versions actually a performance issue?
- Intent so far has been that from the user perspective, fcrepo6 is almost the same as fcrepo5. Autoversioning would not be a large departure from the user perspective.
- Could lose the idea of having significant versions that you would want to roll back to. Maybe introduce a tag concept in OCFL?
- General sense is that if there is a reasonable transaction API, then for the OCFL use case autoversioning would make the most sense and simplify things.
- Jared - Suggestion to store tags which would be logical versions from the fedora perspective, while the OCFL object would keep finer grain versions.
- Multi-object transactions
...