Time/Place
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
- International toll free: http://www.readytalk.com/intl
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
- Once on the call, enter participant code 2257295
- IRC:
- Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #fcrepo on irc.freenode.net
Attendees
- A. Soroka
- David Wilcox
- James R. Griffin III
- Aaron Birkland
- Stefano Cossu
- Unknown User (daniel-dgi)
- Andrew Woods
- Yinlin Chen
- Jared Whiklo
- Doron Shalvi
- Unknown User (acoburn)
- Kevin S. Clarke
- Bethany Seeger
Agenda
Service provider idea? https://groups.google.com/d/msg/fedora-tech/UovyLGZeToE/lNRtWZZ4JM4J
Does fcrepo-webapp belong in the fcrepo4 github project?
- One issue is that there are two webapp modules: one for core, one for core+optional modules. This may not be ideal, especially as more optional modules become available (e.g. fcrepo-audit)
- Another issue is that putting fcrepo-webapp in core ties the reference implementation to a particular deployment strategy (tomcat/jetty). Other strategies, however, may be more appropriate for some adopters (e.g. OSGi or "containerless"). The counter argument is that a reference implementation should be minimally deployable.
- F4 core, extras, and labs (mailing list thread)
- What are the "core" Fedora capabilities/projects?
- Which projects are always included in any given release?
- Should we decouple the version number schemes of optional projects from core releases?
- Should optional projects share the same "org.fcrepo" package namespace?
- What are the criteria for graduating from (1c)? - Practices from Islandora? Hydra?
- What is the policy for deprecating a project from (1a) or (1b)?
- What should the name of a third GitHub organization be, if such an organization is needed?
OSGi:
fcrepo-kernel -> fcrepo-kernel-api fcrepo-kernel-impl -> fcrepo-kernel
...
Current Priorities
Tickets resolved this week:
Tickets created this week:
Minutes
- Welcome Bethany Seeger - Library dev at Amherst, working with A. Coburn
- Service provider
- Elliot + Aaron - moving conversation forward soon
- Initial proposal/sketch has been provided to the community
- Goals of effort:
- Add capability through community contribution
Collaboration across islandora/hydra
- common service layer
- similar to pcdm
- security layer
- including indexes
support for content modeling
aaron birkland
- not quite a proposal, need more community involvement and requirements
- stefano brings actual content modeling
- stefano's useful in shaping aarons "proposal"
- effort will be launched in early fall
call for participation: stakeholder, reviewer, developer
xx + put out call for participation
- stefano motivated to move the forward
- fcrepo-webapp in fcrepo4
- Esme: it would be nice to have one project: more coherent releases, less confusion; however demoting frepo-webapp does not look good
- Adam: the only reason we have webapp-plus is because of bad deployment architecture. Ideally we would have one deployable artifact for both
- Danny: agree; expect to have a deployable and configurable artifact. I should be able to enable specific features, not an all-or-nothing deal.
- Andrew: We have 2 possibilities:
- OSGi, which offers a high degree of runtime configurability
- externalizing components and make them more configurable than current ones
- Adam: there is a difference between configuration (how you make your components work) and wiring (which components you enable). Those are the same as of now, due to Maven which is not the ideal tool for this job
- Andrew: Webapp-plus is mostly wiring
- Adam: That is because Modeshape owns that configuration; there has been extensive discussion about unpacking that config
- Aaron B: Regarding API extension arch: as far as implementation, we would design it as modular as possible - that is conceptualized and outside of Fedora, not dealing with Modeshape stuff. We need to discuss how to approach modularity; also how to live with specific Modeshape config
- Adam: you need to configure Modeshape options somewhere to enable any of the webapp-plus modules
- These modules cannot do their thing via a client?
- Adam: No, unless you want to run them on pure LDP (HTTP) - and performance would suffer
- Andrew: confirm that auth modules are relying on Modeshape because they pass through it before they are delegated to our custom module
- Andrew: Back to the original question: is there anything that we can focus our energy on to improve the way we have wiring and config in one?
- Adam: There are some options:
- Configuration: OSGi, very powerful and not too hard to configure - there are some standard patterns on how to store config
- Wiring: There are OSGi services; Spring can even do wiring with some care. for module level wiring, OSGi is the best - maybe Java 9
- Danny: We are about to push out an OSGi deployment but not many have the resources to do that
- Adam: there is a difference between OSGi frameworks and containers. You can put OSGi in containers (e.g. Karaf). The hard part is actually the OSGi part, which is a lot of work
- Aaron C: leaving webapp where it is is fine; the question is moving toward OSGi which happens step by step. Once there, deployment will be more flexible. Rather than expending resources in figuring out how to separate current webapps we should focus on how to move to OSGi
- Andrew: seems like there is a recognition toward moving OSGi - let’s put together a plan
- Aaron C: Not everyone knows what OSGi is and what it can do; we can explain that and what those incremental steps are to make Fedora deployable as OSGi
- Aaron will create a page on the Wiki and inform the community
- core, extras, labs:
- There is consensus on having three separate Github organizations: fcrepo, fcrepo–labs, and fcrepo-extras.