2023-07-17 - Application Formalization

Marc Johnson will take notes from the recording.  Thank you!

Vince

Background:

• A presentation of this information has been given at a summit meeting in June 2023 at University of Chicago.
  • See https://docs.google.com/document/d/1W1Pknn84cNd8esuv2BCzYXZunnZ66jNb9gQOhvSiQ78/edit?usp=sharing
• The purpose of this discussion is to share with a wider audience, specifically the Technical Council.
• This is the first of a series sessions.  Additional dedicated discussions will likely be required to get through all of the information.  
• There are several WOLFcon sessions planned which will touch on these topics.  

Notes:

• Tobias Stumpp Asked if app dependencies are other apps? VBar confirmed that to be the case and that dependency checks will be performed at the application level. When any module in an application needs to be upgraded, then the application needs to be upgraded and it's dependents checked. Marc Johnson asked if there are multiple kinds of dependencies e.g. a platform or an application? VBar  confirmed that there will dependencies of different types
•  (In the context of modules sharing access to the same database) Tobias Stumpp asked if this would support different access types e.g. read only, as write access to shared databases could cause some trouble? VBar stated the primary, beneficial use case is to allow multiple modules read access, however there might be cases where shared write access could be desirable, e.g. to support extension modules. However in general, we to avoid different parts of FOLIO stepping on each other.
• Marc Johnson Asked if this proposal included substantive changes to how modules work in FOLIO, e.g. shared database access? VBar stated that the changes to modules are separate concepts, enabled by the formalisation of apps. Marc Johnson How is that achieved when applications are an optional structure in FOLIO? VBar stated that this is a progression of the concepts, that could be aligned or separate depending upon where we go in the future
• (In the context of initial loading of application bundles)Maccabee Levine Asked if implications of applications is intended to be characterised as negative? VBar confirmed that they were and expanded upon the positive benefits: independent lifecycle for UI modules / applications and greater flexibility of configuration. Craig McNally Added that scalability for hosting providers managing many tenants would be improved (through not having to build tenant specific bundles).Maccabee Levine suggested there might be trade offs for single tenant providers. VBar stated that they still receive the application lifecycle benefits and that single organisation hosting might still want multiple tenants, e.g. multiple colleges. The upcoming consortial support for Mobius might open up options in this area
• (In the context of dynamic loading of application bundles) Marc Johnson asked whether the user that chooses when to activation was the staff member using the system or an administrator? VBar stated that this is still to be decided and may be based upon metrics, like how many users are interacting with that application, and send notifications to those users. Marc Johnson asked how the challenge of rolling out applications is different to the way the system is rolled out today? VBar suggested that it moves that challenge to per-application rather than the whole system

If you have questions which we didn't have a chance to get to today, please add them below and we'll get to them at the start of the next session.  Thank you!

• VBar : Can you also provide your presentation slides? Thanks!
  • https://docs.google.com/presentation/d/1b15PpMQKN93bF9eSEZv060_AAvhzScTWU85oo88mfIk/edit?usp=sharing

Added after the meeting as requested:

• Maccabee Levine Reading the full Application Formalization proposal document, I don't yet understand the implications of dependencies between applications (hope that will be covered in an upcoming presentation).  Assuming we define some Inventory application as including ui-inventory (alone) on the UI side, it seems that the many other applications whose UI modules link to inventory would have to depend on that application.  So would a breaking change to ui-inventory then require a new release not only of the Inventory application but also all other applications that depend on it?

• Maccabee Levine If we call this new bundle-of-modules thing an Application, then at the same time we also need a (new) word for the top-layer UI buttons that many end users currently call apps or applications, i.e. "Check in".  This is semantics but important, otherwise we add a ton of confusion for end users.

• Maccabee Levine The first presentation was great in discussing both pros & cons of the suggested approach.  The document's "Conclusions" section lists only benefits and should be expanded in the same way.

Discussed briefly after the presentation, at the 7/19 TC:

• Jenn Colt asked when & how this would be shared with PC and CC their input.  Marc Johnson had a similar question.  Maccabee Levine agreed that while this is a technical proposal, it has impacts on CC and PC concerns.  For example "Release Simplification" / ease of deploying new Applications has implications for how Applications are approved (how related to PC's new process?), the marketing of flower releases (CC), and the "definition" of the proposed platforms like "FOLIO LSP" (maybe all three councils).