Mental model for resource lifecycle
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 563
- Forks
- 108
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 3
Description
Since CS possess a Physics Envy on certain occasions, we might as well go with it to form a mental model. ;-)
I'm of course referring to the concept of atomic operations, and then what constitutes an atom, because atoms have substructure.
Atoms have a nucleus, which again consists of protons and neutrons. In Solid's first iteration, I think we should study the Hydrogen atom much like Niels Bohr did more than a hundred years ago. Thus, we have a single proton. That proton is "the resource", because it positively charged and can attract... whatever. :-)
The neutrons are the resources that lives and dies with the proton, i.e. the .acl (#58) and the .meta (#63). That is, operations on these resources are not only atomic, their lifecycle are completely tied together, and so operations on the proton may cause side effects on the neutron resources.
Beyond the nucleus, there are electrons, but as free hydride anions exist only under extreme conditions, we should restrict ourselves to only one electron per nucleus for now. The electron is typically the server-controlled metadata (#65), i.e. data that should be manipulated atomically with the nucleus, but when the nucleus is destroyed, the electron may persist. It thus to be expected that the pod graphs will be a negatively charged plasma, with free electrons representing data about long-gone resources.
Slightly tongue-in-cheek, but I think this mental model captures some essentials :-)
But the big question, does it capture consensus around resource lifecycle?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with this issue and the referenced issues #58, #63, and #65 to understand the proposed resource relationships. The work is complete only when the project reaches consensus on the lifecycle model and identifies a concrete specification change.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100