2021-10 - PWV - Client Cache Garbage Collection

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.

Contributor Log

In-progress

1 Like