Name: Dependency Proposal
Organization: PWV Consultants
||Hours||Rate / Hr.||Period|
After the month-end, you’ll finalize your logs and then create a Snapshot proposal, referencing this page. And then here, you can reference the link to your Snapshot proposal.
Currently there is no functionality or difference between dynamic URIs, such as ENS domains, and static URIs, such as IPFS CIDs, within Polywrap. This can cause an issue if the underlying wrapper is changed for the these dynamic URIs, as it could stop an existing app from working or provide unexpected behavior. This proposal is to spec out the ability to cache the underlying static URI associated with the current dynamic URI. This will allow for these dependencies to be resolved as expected every time.
See Polywrap Dependency Locking · Issue #402 · polywrap/monorepo · GitHub for github issue.
Architecture Plan will be delivered along with estimates and paths for execution and development of the following features:
- Review and comparing existing implementations dependency locking (package-lock.json, requirements.txt, Cargo.lock, docker-compose etc.).
- Implementation details related to how to lock these URIs down (file/folder).
- Implementation details of how to keep these up-to-date and path for updating the locks.
- Implementation details as to how, when, and where to generate the locks.
- Pros and cons of specific implementation details related to security/efficiency and developer friendliness.
- How the implementation will affect redirects.
An architecture plan will lay the roadmap for further execution and development that includes the following elements:
This section will outline Background Context, Scope, and Requirements.
This section breaks down each component of the architecture of the project describing what and how and why.
This lays out the physical and cloud infrastructure components and how they relate to each other.
This lays out the individual components. For instance a Data Decryption component - where it lives within the system.
Outlines how do the components communicate with each other.
Lays out the literal steps in the processes from component to component via a real-world scenario(s).
This outlines the state the data is in.
This will show the timing of how data flows around and through what protocols.
Shows inventory of all things being used, and what other alternate plans/methods were considered
Why we choose this path usually related to pen and paper testing or scenario breakdowns.
Third parties or vendors we source from (cloud/DC/physical).
How this will get out into the real world as a POC.
Estimate of hours for each component of the technical plan.
Supplemental Document (usually a spreadsheet) as needed.
How deliverable of the real world POC will be delivered.
Any outstanding questions or known unknowns. Additional information and or sections are often added depending on the project needs as they develop. Plans are typically 30-150 pages depending on what is sufficient to document what needs to be understood to build the project. The plan is typically presented as a PDF that we review in at least one meeting and then discuss in further meetings and revise for specificity. We have and can on request also modify the plan into a brief slide deck that isolates most of the diagrams, lists, and schedules.