API Review and Refactor Nov 30, 2024 #2
Assignees
Labels
areas::processes::planning
High-level strategy and planning
areas::product::source
Affects product source (code, etc)
tasks:refactor::breaking
A refactor resulting in a breaking change
tasks::refactor::improvement
A general improvement, internal or user-facing.
tasks::review::design
Setup, architecture or design patterns
Comments
This was referenced Nov 30, 2024
Arlodotexe
added
areas::processes::planning
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
With the recent batch of updates to the various OwlCore libraries I've been incubating to support our new community infrastructure, we're ready to move forward with our implementation.
Just to recap from this thread on Discord:
Here be owls! Updates have arrived, full release notes linked
IpfsShipyard.Ipfs.Corewas updated to 0.7.0 with major fixes and API alignment with Kubo.IpfsShipyard.Ipfs.Http.Clientwas updated to 0.6.0 with similar implementation-side improvements.OwlCore.Storagewas updated to 0.12.1 with improvements toSystemFileandSystemFolder.OwlCore.Kubowas updated to 0.20.0 with support for Filestore and the API improvements in the shipyard.OwlCore.Nomadwas updated to 0.9.0 with cleanup of extraneous lifecycle-managed properties and support for multi-domain event streams.OwlCore.Nomad.Storagewas updated to 0.9.0 with no notable changes, mostly cleanup.OwlCore.Nomad.Kubowas updated to 0.14.0 with new tooling for root-level event stream handler lifecycle management.OwlCore.Nomad.Kubo.Storagewas updated to 0.14.0 to implement the underlying updates and add aStorageRepoFactoryfor easy lifecycle management (unit tested).This concludes ~2 months of research and planning largely centered around container ownership and operations. With the changes fully validated on a working implementation, now we know exactly what to do and how to do it in the new community infra.
Problem
Our API is outdated and full of leaks and holes. Using insights learned from the various libraries we've built we can identify several potential pitfalls and shortcomings in our current setup.
Before we can move forward with the implementation, we must review and refactor our API surface for both Models (serialized objects) and AppModels (interfaces).
Solution
We've performed a full analysis of the API and have identified additions/removals/changes that need to happen to both models and AppModels simultaneously.
We've split this analysis into two sections: Lists and properties. Each section lists what's extra and what's missing for each of the three types.
Lists:
Current setup
Publisher
Project
User
Changes to make:
[What's extra]:
Publisher doesn't need:
Project doesn't need:
User doesn't need:
[What's missing]:
Publisher is missing:
Project is missing:
User is missing:
Properties:
Current setup
Publisher
Project
User
Changes to make:
[What's extra]:
Publisher doesn't need:
Project doesn't need:
User doesn't need:
[What's missing]:
Publisher is missing:
Project is missing:
User is missing:
These changes need to be applied to:
Ignore any build errors for now, we have no implementations but changing things might affect our event entry records. The work within each task can be split up at each order, descending. We'll PR any concurrent work into the PR for order n+1. e.g., Two PRs A and B merge 1) into
main, four PRs A1-A2 and B1-B2 merge into A and B (respectively), and so on as needed.Once all the above is completed, we can adjust our event stream entry records and serializer and begin the implementation of the AppModels using the models we've just refined.
I'll create sub-issues to elaborate on the exact requirements for these tasks a bit more.
Tasks
The text was updated successfully, but these errors were encountered: