UpEnd

Essential

alternativni pristup k filesystemu
file storage jakozto database; database jakozto file storage
fs ⇋ db ⟹ allmighty library
ahierarchickej // polyhierarchicky pristup...

Cut word lines Cut music lines Smash the control images Smash the control machine Burn the books Kill the priests Kill! Kill! Kill!

William S. Burroughs - The Soft Machine (1961)

Summary

#czech

v podstate moje idea je :

Base structure

databaze kde mas dva druhy objektu: data, a meta

(jedinej rozdil je, ze data actually odkazujou hashem na nejakej file, a meta neodkazujou nikam, jenom slouzej jako "anchor")

a ke kazdymu objektu muzes mit arbitrarni keys a values

kazdy takovy key/value tvori jeden E/A/V triplet (see Entity Attribute Value model (Wikipedia)):

Entity = objekt (neconeco.mp3, resp. jeho hash)

Attribute = klic (year)

Value = hodnota klice (2020)

struktura filesystemu samotna je taky E/A/V triplet: FILE_shaiusdhuijhngsoyuhsdf BELONGS_TO_DIRECTORY shaoidsuhjaoijoiasjdioj

(kazdej E/A/V je taky objekt na kterej se da odkazovat, kdyby sis chtel anotovat anotace)

Schemas

objekty maj kategorie, ktery znamenaj ze se muzes spolehnout ze objekt co je otagovanej "radio" ma: cas pridani, slozku, heaviness, etc.; co je otagovanej "public" ma: "projekt", "filetype", "rok", etc.

to je taky E/A/V triplet: Entita je ten objekt, Attribut je neco jako IS_A a Value je odkaz na kategorii (ktera je taky objekt slozeny z E/A/V tripletu - znacici co musi objekt splnovat)

Input

pridavas soubory bud pres web rovnou do databaze, nebo AREAS/DigitalGardenAnabasis/syncthingoidne do filetree, a pak zarazujes

Output

output je bud ten, ze je ven exposly jakysi APIcko, ktery ti dava jenom pristup do jedny z moznejch hierarchii, a s tim pracuje treba radio, nebo photo uploader, nebo OCRko

nebo ten, ze to proste pouzivas misto file browseru, ale kdykoli mas moznost se vratit zpatky na baseline concepts.filesystem kdyz najdes, co hledas

Geekmiscellanea

extremne zmateny notes z prubehu konceptualizace (pravdepodobne useless pro kohokoli jinyho)

(clarification - neni to teda jenom key/value, zjistil jsem ze se tomu rika entity/attribute/value, kdy ten key/value je jenom ta posledni dvojice, a "entity" je nejakej abstraktni anchor ke kterymu se pojej ruzny key/values; moje pointa je, ze entity nemusi bejt enom IDcko na ktery vazes, ale i primo data, ktery muzou existovat tim padem na vic mistech / jako vic filu zaroven (nebo taky zadny), a i ty samotny vztahy mezi entitama, cimz ti vznika moznost i nejak znackovat co vlastne o tech datech rikas)

Goals

~~democratic user interface model a la Syncthing~~
~~Content-Addressability~~
~~K/V metadata store~~
schemas / constraints on metadata
- (auto-admin?)
Links between objects
- 1-way = Tags
- 2-way = Relations
- ~~3-way = ???~~
1st order tags
1st order links (?)
kompozice souboru
- skrz schemata! (sub-objekty pojici se k jedne ci vice entitam)
Modes
- R/O only
- Hybrid
- Full
FS revisions / metadata only backups
staging area, queues...

Design

Schemas

Databases that are “schema-less” give you great flexibility and power when putting data in, and are extremely unhelpful when getting it out. A key-value store is a more technical version of “free text”, with the same drawbacks — it is pretty unhelpful when you want to extract info or do anything with the data, since you cannot guarantee that any specific keys will be there.

Luke Plant - We need less powerful languages