Name: Client Cache Garbage Collection Proposal
Organization: PWV Consultants
Requested Grant
| Wallet | Stable Coins | WRAP |
Hours | Rate / Hr. | Period |
|---|---|---|---|---|---|
0x6F2aC911479A921cddB68FDB0cC027Ca1e0C1Ea0 |
USDT |
40 hours | 165 USDT/hr |
October 2021 | |
0x6F2aC911479A921cddB68FDB0cC027Ca1e0C1Ea0 |
USDT |
16 hours | 165 USDT/hr |
November 2021 |
Snapshot
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.
Summary
Polywrap currently implements a client cache for each wrapper that is used for the entire lifetime of the client instance. This can cause scaling issues in the future as the cache can become bloated when many wrappers are queries and downloaded into the cache. To correct this there will need to create a system that allows some form of rules related to when the application should remove certain wrappers from the cache.
Detailed Deliverables
Architecture Plan will be delivered along with estimates and paths for execution and development of the following features:
Dependency Locking
Known Deliverables:
- Review and comparing existing implementations of garbage collection such as Apollos gb/cache eviction, Rust (no real GC, optimized) etc.
- Implementation details and components related to garbage collection.
- Suggested implementation for rules related to how to allow developers to specify the behavior of the garbage collector.
- Implementation details related to how to cycle through without erroring out if limit is hit.
- Pros and cons of specific implementation details related to security/efficiency and developer friendliness.
An architecture plan will lay the roadmap for further execution and development that includes the following elements:
Introduction
This section will outline Background Context, Scope, and Requirements.
Technical Plan
This section breaks down each component of the architecture of the project describing what and how and why.
System Diagram (network topology)
This lays out the physical and cloud infrastructure components and how they relate to each other.
Component Diagram
This lays out the individual components. For instance a Data Decryption component - where it lives within the system.
Component Flow
Outlines how do the components communicate with each other.
Sequence
Lays out the literal steps in the processes from component to component via a real-world scenario(s).
Data Lifecycle Diagram
This outlines the state the data is in.
Data Transfer Flow Diagram
This will show the timing of how data flows around and through what protocols.
Tools/Stack/Protocols
Shows inventory of all things being used, and what other alternate plans/methods were considered
Reasoning and Determination
Why we choose this path usually related to pen and paper testing or scenario breakdowns.
Providers
Third parties or vendors we source from (cloud/DC/physical).
Deployment/Release
How this will get out into the real world as a POC.
Component/Time Breakdown
Estimate of hours for each component of the technical plan.
Hard Costs Estimate Schedule
Supplemental Document (usually a spreadsheet) as needed.
Delivery
How deliverable of the real world POC will be delivered.
Questions:
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.