Oletetaan, että käyttäjä tallentaa dokumentin mediakirjastoon. Kuukauden päästä nimi, kansikuva ja kuvaus ovat tallella, mutta toisto ei ala. Käyttäjälle sisältö on rikki. Kehittäjälle luettelomerkintä voi olla täysin kunnossa: tiedoston lähde on poistunut verkosta.

Vika osoittaa kolme erillistä kysymystä: löytyykö sisältö, ovatko vastaanotetut tiedot oikeita ja saadaanko ne nyt? Yksi ”julkaistu”-tila tekee käyttöliittymästä optimistisemman kuin järjestelmän todelliset kyvyt.

Luettelo kuvaa sisällön, tiedostot tarvitsevat lähteet

Nimet, tekijät, kanavat, tunnisteet ja versiosuhteet muodostavat luettelon. GUNin julkinen dokumentaatio kuvaa graafitietoja ja vertaisten tilan reaaliaikaista synkronointia. Tällaiset työkalut auttavat järjestämään ja synkronoimaan suhteita. GUNin projektikuvaus

Tiedostojakelun kysymykset ovat toiset: kuka säilyttää kokonaista kopiota, mitkä solmut ovat verkossa, onnistuvatko yhteydet ja puuttuvien osien haku? Säilynyt luettelomerkintä ei automaattisesti täytä näitä ehtoja.

Näytä luettelon tila ja hakutila erikseen. Käyttäjä voi ensin tallentaa merkinnän, mutta sivun pitäisi kertoa, onko saatavuus tarkistettu hiljattain. ”Viimeksi haettu onnistuneesti” ja ”lähde saatavilla nyt” tarvitsevat eri sanamuodon, jotta historia ei muutu reaaliaikaiseksi lupaukseksi.

Ero auttaa myös vianetsinnässä. Jos luettelo synkronoituu mutta tiedosto ei löydy, tarkista ensin säilytys ja siirto. Jos tiedosto saapuu mutta versio on väärä, tarkista luettelon ja sisältötunnisteen yhteys. Ongelmat vaativat eri korjaukset.

Sisältöosoitteet ratkaisevat tunnistamisen

IPFS tunnistaa sisällön CID-tunnisteilla. CID sisältää muun muassa hajautus- ja koodaustietoja eikä ole vain mielivaltaisen tiedoston tavallinen SHA-256-merkkijono. Myös tietojen järjestely voi vaikuttaa tunnisteeseen. IPFS:n sisältöosoitteistus

Mediakirjastossa näyttötiedot kannattaa sitoa selkeästi tiettyyn tiedostoversioon. Kuvausta muuttaessa voi riittää luettelon päivitys. Videon uudelleenleikkauksessa on säilytettävä vanhan ja uuden version suhde, jotta kirjanmerkit, kommentit ja tarkistustiedot kohdistuvat oikeaan sisältöön.

Onnistunut tarkistus vahvistaa luottamusta eheyteen, mutta ei yksin kerro tekijää, lisenssin pätevyyttä tai sisällön sopivuutta käyttäjälle. Älä esitä yhtä tarkistusta yleispätevänä ”luotettu”-merkkinä. Näytä näyttö juuri esitetystä väitteestä.

Pysyvyys tarvitsee jatkuvat säilytysjärjestelyt

IPFS:n dokumentaatio erottaa sisältöosoitteistuksen pysyvästä säilytyksestä ja kuvaa esimerkiksi pinningin. Sisältöä säilyttäväkin solmu tarvitsee sopivan käytettävyyden ja ylläpidon tarjotakseen jatkuvan pääsyn. IPFS:n pysyvyys

Julkaisuprosessiin pitäisi siksi kuulua todellinen säilytyssuunnitelma: kuka ylläpitää kokonaisia kopioita, kuinka pitkään, kuka jatkaa palvelun päättyessä ja miten vastuu siirtyy ylläpitäjän lähtiessä? Onnistunut latausmerkintä ei vastaa kuukausien päästä syntyviin kysymyksiin.

Tarkista ainakin kopioiden yhteiset riippuvuudet. Kaksi osoitetta voi viitata samaan tiliin, laitteeseen tai palveluntarjoajaan. Useat merkityt lähteet eivät takaa, että muut toimivat yhden vikaantuessa.

Harvoin kysytyn sisällön säilytys ja suositun sisällön välimuisti voivat saada eri budjetit. Välimuisti mukautuu kysyntään; pitkäaikaissäilytys tarvitsee nimetyn vastuullisen. ”Kukaan ei katso nyt” ei tarkoita ”ei enää säilyttämisen arvoinen”.

Saatavuustarkistusten on haettava oikeita tietoja

Seuraava työnkulku on lähtökohta. Määritä tiheys sisältömäärän ja palvelutavoitteiden mukaan:

  1. Lue luettelosta tiedostoversio, sisältötunniste ja mahdolliset lähteet.
  2. Yritä muodostaa yhteys ja hakea todellisia tietoja pelkän luettelorajapinnan onnistumisvastauksen sijaan.
  3. Tarkista tiedot protokollan mukaisesti. Otanta todistaa vain tutkitut osat, ei koko tiedostoa.
  4. Kirjaa aika, toimiva lähde, virheen syy ja tarkistuksen laajuus.
  5. Lisää kopioita tai näytä selkeä tila, kun lähteet vähenevät tai virheet jatkuvat.

Anna tarkistuksille oma liikennebudjetti. Suuren kokoelman täydellinen lataaminen kerralla voi tehdä tarkistusjärjestelmästä pääkuorman. Jaa kevyet kokeet, toistotestit ja ajoittainen täydellinen palautus eri tasoihin ja kerro, mitä kukin todistaa.

Aikakatkaisua, puuttuvia oikeuksia, poistettua julkaisua ja tarkistusvirhettä ei pidä kaikkia kutsua ”puuttuvaksi tiedostoksi”. Erot ratkaisevat, yritetäänkö uudelleen, pyydetäänkö pääsyä, korjataanko kopio vai kunnioitetaanko tekijän peruutusta.

Näytä käyttäjälle mahdollinen seuraava askel

Loputon latauskuvake antaa tuskin lainkaan toimintaohjeita. Kerro mieluummin, etsiikö järjestelmä lähteitä, muodostaako se yhteyttä, ovatko lähteet tilapäisesti poissa vai hylättiinkö tarkistuksessa epäonnistuneet tiedot.

Jos toisto ei ala, käyttäjän pitäisi tietää, kannattaako yrittää uudelleen, löytyykö toinen lähde ja voiko kirjanmerkin säilyttää. Virheilmoituskanava voi liittää mukaan sisältötunnisteen ja virheluokan ilman, että käyttäjän on kuvattava jokainen vaihe uudestaan.

AlphaBizin julkinen arkkitehtuuri mainitsee GUNin ja WebTorrentin. Siksi luettelotietojen ja mediasiirron työnjako on olennainen suunnittelukysymys. Tässä esitetyt menetelmät ovat arvioitavia vaihtoehtoja, eivät väitteitä jo toteutetusta valvonta- tai kopiointistrategiasta. AlphaBizin projektikuvaus

Aloita yhden sisällön palautusharjoituksesta: poista alkuperäinen lähde verkosta ja kokeile palauttaa pääsy säilyneen luettelon ja kopioiden avulla. Tulos kertoo enemmän kuin aina näkyvä kaunis merkintä. Jaa saatavuussuunnitelma ja tarkistuksen laajuus AlphaBiz Discussionsissa.