...
- frank asseg
- Ed Fugikawa
- Andrew Woods
- Stefano Cossu
- Nikhil Trivedi
- Scott Prater
- Osman Din
- Eric James
- Greg
Agenda
4.0 Features: review of responses
Feature Votes (out of 7) Authorization 5 Backup 4 Batch Operations 1 Clustering 5 Content Modeling - Structural 5 Managed External Datastreams 5 Store/Deliver Large Files 6 Search 7 Transactions 3 Triplestore 6 Versioning 4 Non-Functional: Easy Deployment 6 Non-Functional: Performance - Single-node 4 Non-Functional: Performance - Clustered 3 - Resource locking model
- Configuration and support of both protected and public endpoints (Greg Jansen)
- Bring the meat ax down on our leakage of JCR abstractions through our API and RDF (Michael Durbin)
- Fedora ontologies and concept mappings
- other...?
Minutes
1. 4.0 Features: review of responses
Andrew and Greg: The sent out e-mail did not get any negative responses. The feature list covers items that were agreed upon by stakeholders and developers.
The idea was to check was to: 1. check off 2. raise any features not on the list, or re-think
The idea was to prioritize features that are most important to developers (representing institutions send out a broader message, saying that these are the features for 4.0 which drive the focus of development, in order to get sign off from stakeholders.
The page shows where preferences lie.
Greg: With respect to clustering, there are two distinct use cases: (1) performance; (2) redundancy. Wondering if we have emphasized that. There are some expectations in the community about redundancy.
Andrew:Yes, two distinct things. Wondering if we talked about, perhaps only Ed has hinted at that at (some point). Do other folks think that's true
Response: makes sense to talk about it
Andrew: Any other suggestions?
Esme: In our case (and as mentioned in e-mail), a lot of these features in implemented in the front-end (via hydra). So even if F4 beta has no auth, it'd still be an acceptable product.
Andrew: These discussions are taking place.. exploring the idea that hydra starts to leverage F4
Martin: Same applies to Islandora.
Andrew: I encourage conversations with Islandora as well. With David Wicox on board, we should get these conversations going. There are different perspectives when it comes to the repo. One group wants to push functionality down to the lower level, and other group wants a minimal repo that focuses on key cases, such as preservation. It is up to us to draw the right line.
Esme or Scott: Auth could be externalized. Versioning, search, content modeling are good.
Andrew: Let's keep the discussions around. After discussion with stakeholders, we have this list.
Stefano: People might find that F4 is a compeltely different product from F3 in terms of features. Lack of features may put implementation burden if some features are absent (e.g. does auth have to be implemented in client?).
Andrew: agreed. bu the first focus of 4.0 release beta is not upgrade.. subsequent releases will make it easier to upgrade.
2. Resource locking
Mike summarizes the problem. There's some locking which is not there and can be misleading. We need to explore jcr locking functiionality.
Adam: discusses 2 different proposals.
Mike: No personal preference, but need to do something that works
Adam: resources that exist in repo, or in http api.
Andrew asks whether JCR spec talks about node being creating representing a lock.
Adam: No, it's an implementation concern.
Andrew: So, it's a question of where does this thing reside
Mike: If you delete the node, the lock disappears or not. . .
Adam: not sure...
Mike: we can figure out as we implement this
Andrew: any design ideas before you code that you can share would be good on irc and ticket