5min | Updates on RFCs, PoC, etc | Craig, others | |
| | All | Next steps Understanding initial grouping would be helpful Understanding day one impacts is impacted by the initial grouping Triage What questions really need to know the grouping What have we answered What need input from outside the group What is provisionally answered but dependent on other decisions If after that figuring out initial bundling then ok
Day one concept Breaking down into smaller processes, not needing everything done for day one Pick a domain and start working At some point EBSCO's work will be added and there will be an intention to distribute applications? What needs to be done when that happens The first flower release based on applications rather than module release The stuff outside of the technical work
Goal to eventually refactor into some applications Is there value in defining one application? Get enablers in and then iterate on the applications themselves
Charge to answer questions from the councils Applications start here with dependencies start with application descriptor most inter dependencies, fewer external dependencies
The other stuff LC work will come in in the form of applications How to fix existing code vs new applications New LC apps, even people in legacy could introduce new applications. New applications come in as applications Stuff - go from oh good new application descriptors the community actually using the descriptors to build their systems Folks need to actually be using them to get the value things in community, getting new tech in, getting all of that in and getting all of the stuff
|
| | | zoom chat: 00:03:57 Jenn Colt: https://folio-org.atlassian.net/wiki/spaces/CC/pages/116031510/2024-03-27+Formalization+Working+Group+Meeting+notes
00:12:13 Kirstin Kemner-Heek: +1 to the placeholder
00:23:31 Wayne Schneider: Dependencies are currently based on interfaces
00:24:27 Marc Johnson: Reacted to "Dependencies are cur…" with ðŸ‘
00:25:24 Craig McNally: Replying to "Dependencies are cur..."
and that doesn't go away. Modules still need to declare their interface dependencies
00:25:57 Craig McNally: Replying to "Dependencies are cur..."
it's just that the dependencies are summarized at the application level as well
00:26:02 Marc Johnson: I didn’t think we had decided what the application boundaries are
00:27:04 Wayne Schneider: Replying to "Dependencies are cur..."
As interfaces or as module versions (i.e. implementations of interfaces)?
00:27:29 Charlotte Whitt: Yes please split out MARC Authorities, SRS our of Inventory :-)
00:27:49 Tod Olson: Replying to "Dependencies are cur..."
I think we will need to move towards interfaces.
00:28:05 Tod Olson: Replying to "Dependencies are cur..."
But that will also be a big change.
00:28:28 Craig McNally: Replying to "Dependencies are cur..."
an example may help... just a moment
00:28:32 Marc Johnson: Replying to "Dependencies are cur…"
It will still be interface versions at the module level AFAIK
At the application level, its application to application AFAIK
00:28:40 Charlotte Whitt: Replying to "Yes please split out..."
Yes, quickMARC should also be it’s own app. Similar to MARVA (BibFrame) is going to be
00:29:15 Wayne Schneider: Replying to "Dependencies are cur..."
And the application is composed of versions of interfaces or versions of modules? I think the examples give versions of modules.
00:29:43 Wayne Schneider: Replying to "Yes please split out..."
Didn't authorities move to mod-entities-links in Poppy? (a minor point)
00:29:58 Marc Johnson: Where do MARC source records live in this new world?
00:30:15 Marc Johnson: Replying to "Dependencies are cur…"
The application versions is composed of module versions
00:30:46 Charlotte Whitt: Replying to "Where do MARC source..."
It should be it’s own storage, similar to Data Graph Storage (or what it is called today)
00:31:08 Craig McNally: Replying to "Dependencies are cur..."
mod-foo provides interface foo and depends on interface foo-storage
mod-bar provides interface bar and depends on interface bar-storage
ui-foo depends on interfaces foo and bar.
app-foobar is comprised of mod-foo, mod-bar, and ui-foo.
mod-dit provides the dit interface and depends on interface foo
ui-dit depends on interface dit.
app-dit is comprised of mod-dit, ui-dit. and has a dependency on app-foobar.
00:31:08 Kirstin Kemner-Heek: But if I break up a lot of modules being their own app -> do I still have the advantage to save effort by "bundling"?
00:31:51 Craig McNally: Replying to "Dependencies are cur..."
I've left versions out of the example above for simplicity, but they are present at the interface, module and application level
00:32:04 Marc Johnson: Replying to "Dependencies are cur…"
Does app-foobar include the storage modules that you defined the example as well?
00:32:06 Kirstin Kemner-Heek: Replying to "Dependencies are cur..."
+1 Craig. That explains :-)
00:32:45 Wayne Schneider: Replying to "Dependencies are cur..."
Thanks. So applications are composed of particular implementations of interfaces (i.e. versions of modules).
00:33:03 Charlotte Whitt: Replying to "Yes please split out..."
I could be wrong. But MARC authorities use Elastic Search, and that was the reason for the decision to build it into Inventory
00:33:05 Marc Johnson: Is there a contract at the application level?
00:33:52 Marc Johnson: Replying to "Yes please split out…"
It’s probably built into mod-search
Which is both general and inventory specific, so where does that belong because ui-inventory needs it?
00:34:41 Charlotte Whitt: Proper sizing is that a ‘same size all bundled modules’ or size fitting the given bundled modules
00:35:14 Craig McNally: Replying to "Dependencies are cur..."
@Marc Johnson that's ambiguous in my example (sorry).
mod-foo-storage provides interface foo-storage
mod-bar-storage provides interface bar-storage
mod-foo provides interface foo and depends on interface foo-storage
mod-bar provides interface bar and depends on interface bar-storage
ui-foo depends on interfaces foo and bar.
app-foobar is comprised of mod-foo, mod-foo-storage, mod-bar, mod-bar-storage, ui-foo.
mod-dit provides the dit interface and depends on interface foo
ui-dit depends on interface dit.
app-dit is comprised of mod-dit, ui-dit. and has a dependency on app-foobar.
00:37:05 vbar: Snakes and ladders is a maybe not the best metaphor since it entirely based on chance (dice) with no skill involved. 🙂
00:37:52 Marc Johnson: Replying to "Snakes and ladders i…"
By all means substitute for a more appropriate game
Apologies if I incidentally offended
00:41:33 Marc Johnson: In the past, teams have made decisions that are impacted by Conway’s Law and we’ve ended up with smaller parts because of team responsibilities
00:45:44 Craig McNally: Replying to "Proper sizing is tha..."
Proper sizing IMO doesn't mean that all applications must have the same size. Rather, it means applications don't have "too much" or "too little" in them
00:57:05 Marc Johnson: Have I completely misunderstood how we are intending to roll out applications?
01:03:39 Craig McNally: I have to run.. thanks guys
01:04:39 Charlotte Whitt: FOLIO legacy … 😅
|