This is a partial list of issues raised at the Mid-west Fedora Users Group around changes to the Modeshape implementation or missing features of the Fedora Modeshape Implementation. This is not an exhaustive list and is open to be added to/expanded on by anyone.
- Snapshot versioning
This feature is used by the ICPSR team at U Michigan to allow people to create a static snapshot of their published research. There were concerns raised about how the change to a single object versioning would affect their application. This was identified by Harsha Ummerpillai, perhaps he can elaborate on the details here.
An issue when trying to perform multi-threaded writes was identified by Harsha Ummerpillai, perhaps he can elaborate on the details here or on - FCREPO-2800Getting issue details... STATUS .
- Better support for replication (possibly through the use of warm backups)
Fedora's clustering support is lacking, it has been underutilized and/or not well tested. It was suggested that this feature could be of benefit to people with concerns about downtime. This was also identified by Harsha Ummerpillai, I think I have misunderstood the main suggestion though.
- Internal search functionality versus an external index and the concerns of losing sync between those two.
One concern expressed was that without having an easy way to find objects in your repository, we are always relying on an external service to store that list. If anything happens to cause a difference between that external index and the repository you have little recourse other than to re-index the entire repository again. Re-implementing some sort of search functionality would make this issue easier to resolve.
- Clarity to Fedora's scope
This is more of a ethereal thing, but my take on the discussion was that there is some confusion as to what the Fedora repositiory's role is inside of a system architecture. While this will be different things to different organizations, if Fedora had a clearer scope it might make determining its place in the architecture easier. I think Stefano Cossu had some thoughts on this topic, perhaps he can clarify if I am on the right track.
- Ability to disable the internal ActiveMQ broker.
Currently to completely disable the internal ActiveMQ broker you need to comment out the bean in the spring configuration. This might be easier in Fedora 5.0.0 with - FCREPO-2393Getting issue details... STATUS as it will be easier to store the configuration outside the application. If not perhaps some sort of configuration option to disable the internal broker can be added?
- Better documentation on disk space requirements related to temporary disk.
When uploading a file to Fedora it appears that the file is not streamed directly to the repository. Instead it is copied to the web-app container's temporary directory (Tomcat for instance). Is this because we don't support streaming inputs or require some special Tomcat configuration? At the very least having some information to inform those who will have large uploads to size their temporary directory accordingly.
- Monitoring tools
There was a desire for a reliable way to ensure the health of one's Fedora repository. Carrick Rogers shared how he created a small "hidden" container at the root of his repository that the DevOps people can ping as a heartbeat check. Some dedicated, small impact location for this type of service seems like it would be desirable. - FCREPO-2799Getting issue details... STATUS
- Development in non-Java languages.
It seems that Java while powerful is also one of the reasons people don't feel they can help out in code development, bug fixes, etc. The possibility of Fedora implementations in different languages (ie. LakeSuperior in Python) raised a lot of interest.
- Help moving Modeshape on S3 support into core.
Carrick Rogers mentioned the PR (https://github.com/ModeShape/modeshape/pull/1668) that Northwestern requires for their architecture. They currently have to compile a custom Fedora to make use of a patched Modeshape. This keeps them from being able to assist in testing as their setup is non-standard. The issue with that PR (in Jared Whiklo's opinion) is that it is a static set. Perhaps re-working the PR to allow for a configuration choice would get it into modeshape more easily.
- Add your own....