Bindery ja dokumendid ilma liimkoodita
Fail ei olnud probleem
Esimene viga on arvata, et dokument on fail. See saabub failina, jah. Sellel on nimi, tavaliselt laiendiga, mis tundub rahustav. Hankearuandlus ütleb .xlsx, aruanne ütleb .docx, arhiivikoopia ütleb .pdf ja kõik teesklevad, et maailm on lihtsaks muutunud, sest viimased neli tähemärki tunduvad tuttavad. Tore. Siis valetab laiend, töövihikus on peidetud lehed, slaidikomplekt sisaldab manustatud objekte, PDF on enamasti tekst, aga mitte päris, ja vana Wordi fail lõhnab endiselt nõrgalt 2003. aasta järele.
Enamik meeskondi ei ehita dokumenditorustikku. Nad ehitavad väikese muuseumi vormingueranditest. Üks teek Wordi jaoks, teine Exceli jaoks, midagi muud PDF-ide jaoks, kangelaslik kestaskript arhiivikausta jaoks, Pythoni pakett, mida viimati uuendati, kui kõik veel arvasid, et QR-koodid on põnevad, ja mõned regulaaravaldised, mis tuleks õue viia ja vaikselt pensionile saata. Kuus kuud hiljem on liimikiht suurem kui toode. See ei ole haruldane rikkeviis. See on dokumenditöö tavaline kuju, kui igal vormingul on oma kuningriik.
Bindery on olemas sellepärast, et dokumendikiht ei peaks muutuma põhiprojektiks. Rakendustasandil on see Rusti kast nimega dweve-bindery. Avalik leht kirjeldab ühte kasti 17 vorminguga, DocQL-i, Pythoni sidemetega ja ühise mootoriga. Oluline osa on see, et kõrgetasemelised API-d nagu Document, Presentation ja Workbook asuvad vormingupõhiste moodulite kohal OLE2, OOXML, ODF, iWork, RTF, PDF, Markdown, EPUB, LaTeX, piltide, valemite ja DocQL-i jaoks. See loend ei ole seal selleks, et kedagi muljet avaldada. See on seal sellepärast, et päris korpused on ebaviisakad.
Kasulik väide on lihtne: ava dokument ühe mootori kaudu, normaliseeri see, mida saab normaliseerida, ja hoia vormingupõhine valu ühise pinna all. See ei muuda iga vormingut identseks. See teeb erinevused piisavalt selgeks, et torustik suudab need üle elada.
Tuvastamine ei ole kaunistus
Vormingutuvastus kõlab nagu väike utiliit, kuni see ebaõnnestub. Siis saab sellest terve intsident. Laiendid on metaandmed, mille on andnud inimene, tööriist, meilivärav, eksporditöö, migreerimisskript või väsinud praktikant, kes faili viimati puudutas. Mõnikord on need õiged. Mõnikord on need viisakas soovitus. Tõsine dokumendimootor peaks enne otsustamist, milline lugeja faili omab, kontrollima maagilisi baite, konteineri struktuuri, paketiosi, vooge ja sisemisi vihjeid.
Bindery käsitleb seda kui esiust. README ja leht kirjeldavad mõlemad automaatset vormingutuvastust. Teegi dokumentatsioon näitab Document::open ja Presentation::open tavalise teena, mitte vali-oma-parseri tseremooniana. See on oluline, sest kasutajad ei taha enne tabeli eraldamist läbida dokumendiarheoloogia koolitust. Nad tahavad, et mootor valiks tee ja annaks neile stabiilse API.
Siin on kuiv väike õppetund. Mida vähem glamuuri komponendil on, seda rohkem kahju see võib teha, kui inimesed selle kõrvale heidavad. Tuvastamine ei ole glamuurne. Ei ole ka kodeeringu teisendamine, ZIP-käsitsemine, OLE-kataloogi läbimine, seoste lahendamine, Snappy dekompressioon ega XML-nimeruumi käsitsemine. Olgu. Igav töö on just see koht, kus tootmistorustikud muutuvad kas usaldusväärseks või hakkavad õnneamulette koguma.
Üks mudel ei tähenda ühte valet
Ühtne API võib muutuda ohtlikuks, kui ta teeskleb, et erinevused on kadunud. Bindery ei tohiks väita, et PDF, arvutustabel, iWork-arhiiv ja OOXML-pakett on sama asi eri kuues. Nad ei ole. Kasulik arhitektuur ei ole tõde pudruks litsuda. See on avada ühised toimingud seal, kus need on ühised, ja hoida võimaluste piirid nähtavana seal, kus need ei ole.
Lähtekoodi paigutus näitab seda lõhet. On olemas ühtne Wordi dokumendi API, ühtne esitluse API, arvutustabeli tunnused, valemite hindamine funktsioonide taga, DocQL-ühendused ja madalama taseme moodulid vormingute endi jaoks. Avalik vormingumaatriks ütleb, et OOXML ja ODF on esmaklassilised lugemis-, kirjutamis- ja päringupinnad. PDF ja RTF on lugemiskesksed ja kirjutamisel ettevaatlikumad. EPUB, LaTeX ja Markdown on väljundvormingud. Pärand-Office ja iWork omavad oma sisemist mehhanismi. See on õige hoiak. Üks mootor, jah. Üks fantaasia, ei.
See eristus on oluline auditite ja andmetoodete puhul. Kui vastavustöövoog eraldab lepingutest klausleid, peab ta teadma, kas väärtus pärines lõigust, tabeli lahtrist, slaidi märkusest, valemist või PDF-i tekstijooksust. Kui sisseandmistöö toidab otsingut, peab ta teadma, kas pildid, kommentaarid, metaandmed ja seosed säilitati, eirati või märgiti mittetoetatuks. Vastus ei saa olla maetud parseripõhisesse joonealusesse märkusse, sest see märkus ei ilmu, kui keegi küsib, miks tulemus muutus.
Dokumendid on struktureeritud andmed, mis unustasid seda tunnistada
Halvim, mida dokumenditoru saab teha, on taandada kõik liiga vara tekstiks. Tekst on kasulik. Tekst ei ole kogu dokument. Arvutustabelis on valemid, viited, lehed, read, lahtrid, arvuvormingud, kommentaarid ja töövihiku struktuur. Esitluses on slaidid, kujundid, pildid, märkused, järjestus ja mõnikord ettevõtte mall, mis on puhta pahatahtlikkusega üle elanud kolm ühinemist ja ühe ümberbrändingu. Wordi dokumendis on lõigud, jooksud, tabelid, päised, jalused, stiilid, seosed ja manustatud objektid. PDF-is on voogud ja paigutusotsused, mis võivad lugemisjärjekorrale vastata või mitte. Kõige selle muutmine üheks lamedaks stringiks on kiire, lohutav ja sageli vale.
Bindery kõrgetasemelised API-d on kasulikud, sest nad hoiavad dokumendi kuju elus piisavalt kaua, et esitada paremaid küsimusi. Dokumendi API avab lõigud, jooksud, tabelid, read ja lahtrid. Arvutustabeli moodul avab töövihiku ja töölehe tunnused. Valemimootor katab suure Exceliga ühilduva funktsioonipinna. DocQL lisab dokumendimudelile SQL-laadse päringukeele, kusjuures lähtekoodipuus on lekser, parser, valideerija, planeerija, täitja, ühendused, väärtused ja funktsioonid. See on rohkem kui mugavuskiht. See on viis lõpetada sama eraldusloogika ümberkirjutamine iga vormingu jaoks.
Kujutage ette, et esitate ühe korpuse küsimuse: millised lahtrid viitavad sellele eeldusele, millised tabelid sisaldavad riskikategooriat, millised slaidid mainivad poliitikat, millistel dokumentidel on kohandatud atribuut ja millised valemid sõltuvad antud sisendist. Vormingupõhises kuningriigis muutub see neljaks skriptiks ja vabanduste arvutustabeliks. Ühises mudelis muutub see päringupinnaks. Ikka töö, ilmselgelt. Tarkvara kingib sulle harva puhkuse. Aga see on õige töö.
Miks on Rust mõistlik koht selle segaduse jaoks
Dokumendivormingud on imeline kombinatsioon binaarstruktuuridest, pakitud arhiividest, XML-ist, pärandkodeeringutest, pildiandmetest, kuupäevasüsteemidest, valemisemantikast ja turvaprobleemidest. Teisisõnu selline töö, kus ähmane mäluomandus on elustiilivalik koos arvetega. Rust on mõistlik alus, sest Bindery peab tegema hoolikat parsimist, haldama puhvreid, käsitlema vigu valjuhäälselt ja pakkuma API-sid, mis ei sunni ülejäänud süsteemi aimama, mis valesti läks.
Crate'i funktsioonid räägivad sama lugu. Vaikimisi funktsioonid hõlmavad OLE-t, OOXML-i, OOXML-i krüptimist ja eval-mootorit. Täielik tugi lülitab sisse iWork-i, ODF-i, RTF-i, valemid, pilditeisenduse, fondid ja palju muud. DocQL on funktsioon oma binaariga. Valikulised sõltuvused on vastavuses vormingute ja pindadega, mida need toetavad: ZIP-käsitlus, kiire XML-parsimine, kodeeringuteisendus, Snappy, protobuf, pildidekodeerimine, statistika ja kompleksarvud valemitööks jne. See ei ole üks hiiglaslik kogum, mis teeskleb, et iga sõltuvus kuulub igale poole. Funktsioonilipud hoiavad dokumendimootori kuju nähtavana.
See on oluline manustamise jaoks. Teadmussüsteem võib soovida täielikku kontori- ja päringupinda. Väike teenus võib soovida ainult OOXML-i ja teksti ekstraheerimist. Pythoni töövoog võib soovida sideid sama mootori kohal. Käsurea kontrollitee võib olla kasulik ühekordsete päringute ja testide jaoks. Leht räägib Rustist, PyO3-st ja CLI-pinnast; lähtekood näitab DocQL-i binaari ja PyO3 paketti. Oluline disainivalik on see, et need sisenemispunktid asuvad ühel mootoril. Muidu muutub iga integratsioon oma veidi erinevaks tõeks ja siis hakkavad veateated kandma erinevaid mütse.
Hoolduslugu on tootelugu
Bindery't on lihtne kirjeldada parserina, kuid hoolduslugu on tegelik tootelugu. Igal uuel vorminguteegil, mis torustikku lisatakse, on oma väljalasketsükkel, veasõnavara, veatüübid, veidrused, sõltuvusrisk, testifixtuurid ja rikkerežiimid. Väikeses mahus tundub see juhitav. Korpusemahus muutub see operatiivseks toimikukapiks, mis hammustab.
Jagatud mootor ei eemalda vormingukeerukust. See oleks kahtlane. See liigutab keerukuse kohta, kus teste, võimekussilte, funktsioone ja API-sid saab koos hallata. README-s on otsast lõpuni testid dokumentide, esitluste, arvutustabelite, iWork-i ja muude vormingute jaoks. Lähtekoodipuus on moodulid, mis muudavad vormingupiirid ilmseks. See struktuur võimaldab meeskonnal parserikihti parandada ilma, et iga tootemeeskond peaks uuesti õppima erinevust seososa ja liitfailivoo vahel.
See on põhjus, miks Bindery sobib ülejäänud Dweve virnaga. Reed tegeleb sõelumisega koos kviitungitega. BitWeave tegeleb deterministliku otsinguga. Fabric ja Spindle tegelevad hallatud teadmusega ja operatiivse kasutusega. Bindery asub nende kihtide ees. See muudab kontoridokumendid struktureeritud materjaliks, mille üle ülejäänud virn saab arutleda. Kui sisendkiht on liim ja lootus, pärib allavoolu süsteem liimi ja lootuse. Väga tõhus, kui su strateegiline eesmärk on tulevane kannatus.
Mida enne kasutuselevõttu küsida
Esimene küsimus ei ole see, kas Bindery toetab sinu lemmikfailivormingut. See on kontrollküsimus ja kontrollnimekirjad on head, kuid sellest ei piisa. Parem küsimus on, milliseid dokumendilubadusi sa vajad. Kas sul on vaja ainult lugemist, kirjutamistuge, ringlusesse salvestamist, valemite arvutamist, päringuid üle vormingute, metaandmeid, manustatud pilte, krüpteeritud OOXML-i, vanemaid Office'i vorminguid, iWork'i, ODF-i või väljundit EPUB-i, LaTeX-i ja Markdown-i? Need on erinevad tööd. Nende üheks tööks teesklamine on see, kuidas teekaardid muutuvad pudruks.
Teine küsimus on, kuidas tõrkeid nähtavaks tehakse. Kui sõeluja ei suuda struktuuri säilitada, kas ta ütleb seda? Kui kirjutaja on parima pingutusega, kas see on nähtav? Kui valemit ei saa arvutada, kas kutsuja saab otsustada, kas blokeerida, hoiatada või jätkata? Dokumendimootor ei ole usaldusväärne sellepärast, et ta kunagi ei ütle ei. See on usaldusväärne, sest tema ei on tüpiseeritud, konkreetne ja probleemi lähedal.
Kolmas küsimus on, kuidas sa testid oma korpust. Avalikud näited on kasulikud, kuid sinu arhiiv on ilmselt imelikum kui näidiste kaust. Selles on katkised ekspordid, vanad mallid, kummalised numbrite vormingud, peidetud lehed, kopeeritud-kleebitud tabelid, vigased PDF-id ja failid nimega final_final_really_final. Bindery annab ühise mootori ja testitavad pinnad. Sul on siiski vaja korpuse teste. Kahjuks ei kasva dokumendid ise täiskasvanuks.
Õppetund
Bindery õppetund on see, et dokumenditöötlus ei ole tekstieraldus lisasammudega. See on vormingutuvastus, struktuurne sõelumine, võimekuse piirid, päringupinnad, kirjutamisteed ja hooldusdistsipliin. Kasutaja näeb faili. Süsteem näeb konteinerit, vooge, seoseid, kirjeid, stiile, valemeid, metaandmeid, kodeeringuid ja väljundlubadusi. Hea mootor hoiab selle keerukuse toote pinna all, teeslemata, et seda pole olemas.
Bindery ülesanne on muuta dokumendikiht igavaks heas mõttes. Üks Rust-mootor. Kõrgetasemelised API-d dokumentide, esitluste ja tabelite jaoks. Vormingumoodulid segaste osade jaoks. DocQL ühiste küsimuste jaoks. Pythoni ja virna integratsioon seal, kus see on kasulik. Võimekuse sildid vormingumütoloogia asemel.
Fail ei olnud kunagi probleem. Liim oli. Bindery on katse lõpetada selle liimikihi eest üüri maksmine.