Sync

De sync van bae is de sync van coven: bae declareert zijn tabellen en blobs, en coven doet de rest. Deze pagina beschrijft de werking zoals die voor bae geldt; de eigen docs van coven behandelen elk onderdeel volledig.

Vastleggen

coven bezit de SQLite-verbinding, dus elke write die bae commit gaat erdoorheen. Wanneer een transactie wordt gecommit die gesynchroniseerde tabellen wijzigt, legt coven elke rijwijziging, met de kolommen die ze raakte, in dezelfde transactie vast, zodat een gecommitte wijziging nooit verloren gaat, zelfs als de app een moment later crasht. Geen diffs, geen dirty flags: vastleggen is een eigenschap van de verbinding, en een write kan niet worden gemist. De wijziging wacht op het apparaat en wordt pas bij verzenden versleuteld en ondertekend, dus schrijven heeft geen sleutel en geen netwerk nodig.

De reeks

De hele geschiedenis van een bibliotheek in de cloud-home is één genummerde reeks objecten. Elk bevat de batch wijzigingen van één apparaat, een beheerdersvermelding, een sleutel verzegeld voor één lid, of een snapshotaankondiging. Elk apparaat past ze op volgorde toe en slaat er nooit een over, zodat elk apparaat het eens is over wat er wanneer gebeurde. Een apparaat voegt het volgende object pas toe nadat het alle vorige heeft toegepast.

Een sync-ronde leest vooruit vanaf het laatste object dat het apparaat toepaste tot er een ontbreekt, controleert van elk de handtekening en past het toe, stuurt de wachtende wijzigingen van dit apparaat als één nieuw object, en doet daarna het werk dat de nieuwe toestand vraagt: toegang delen of intrekken, snapshots maken, oude geschiedenis verwijderen. Een ronde over een rustige bibliotheek kost twee verzoeken, hoe groot ze ook is.

Rondes draaien na lokale wijzigingen, op een idle timer, en direct bij Nu synchroniseren. Fouten proberen opnieuw volgens één backoffschema, en alles wat niet verder kan noemt waarop het wacht, wat bae in zijn sync-statusregel toont.

Samenvoegen

Twee apparaten die dezelfde bibliotheek bewerken terwijl ze gescheiden zijn, is normaal. Wanneer hun wijzigingen elkaar ontmoeten:

• Bewerkingen aan verschillende rijen of verschillende kolommen passen allebei toe. Het jaar van een release op de laptop bewerken en het label op de desktop levert allebei op.
• Bewerkingen aan dezelfde kolom van dezelfde rij worden geordend op tijdstempel: de latere bewerking wint, deterministisch en identiek op elk apparaat.
• Verwijderingen winnen van gelijktijdige bewerkingen: een bewerking aan een rij die inmiddels is verwijderd verliest, wanneer ze ook aankomt, dus een release die op een apparaat is verwijderd blijft verwijderd, zelfs als een ander apparaat hem in hetzelfde interval bewerkte.

coven bewaart elke vervangen waarde als verloren waarde; bae toont er geen en verwerpt er geen, dus er is geen conflict-UI. Elk apparaat komt tot hetzelfde resultaat vanuit elke aankomstvolgorde.

Snapshots

Een apparaat dat toetreedt of herstelt speelt de geschiedenis niet vanaf het begin af. Apparaten maken snapshots, de volledige toestand van de bibliotheek op één punt in de reeks, en zodra de bibliotheek en elke privékring er een hebben, wordt de geschiedenis daarvoor verwijderd. Een nieuw apparaat laadt de nieuwste snapshot en past daarna alleen toe wat erna kwam. Een apparaat dat langer weg was dan de bewaarde geschiedenis doet hetzelfde, en houdt zijn niet-verzonden bewerkingen.

Schemaversies

Het schema van bae is één migratie, en elke wijziging die een apparaat stuurt vermeldt de schemaversie waarmee ze is gemaakt. Een apparaat dat een wijziging uit een nieuwer schema dan zijn eigen tegenkomt, stopt daar, zonder iets erna toe te passen, totdat de app wordt bijgewerkt; niets raakt kwijt en niets wordt verkeerd toegepast.

Grofmaziger dan de schemaversie is het compatibiliteitstijdperk: de gepinde coven-revisie die in elke binary zit. Twee builds synchroniseren alleen binnen een tijdperk; een breuk in het wire-format van coven is een nieuw tijdperk en een major-versieverhoging over elke app. Voor 1.0 is elke build tijdperk nul en veranderen formaten zonder migratie.

Wat de provider ziet

De provider bewaart versleutelde wijzigingen, snapshots, lidmaatschapsrecords en bestanden; hij kan objecten tellen, groottes en timing observeren en zien welk account elk object schrijft, en niets van de inhoud lezen. Elk object dat een apparaat ophaalt wordt geverifieerd, handtekening en lidmaatschap, voordat iets de database raakt: de opslag is een domme, onvertrouwde mailbox. Zie Encryptie en Identiteit en lidmaatschap.