Miért egy nagy rák az IT-ben a szövegfájl?

Avagy "Akinek kalapács van a kezében, mindent szögnek lát... "

Egy másik topicban előkerült ismét a textfile vs egyebek témakör és hogy ez mennyire hú de fontos is az unix filozófiában. Nos, szerintem ez egy olyan rák, amely több évtizede fertőzi az informatikát és oda csúcsosodott ki, hogy ma a programjaink ahelyett, hogy gyorsan, egyszerűen bináris tartalmakkal kommunikálnak, képtelenek meglenni lassan egy-két-három méretes XML/JSON/akármi feldolgozó nélkül. Na de ne rohanjunk ennyire előre.

Egy valóban nyomós érv a szövegfájlok mellett az, hogy az ember számára jól olvasható, mindenféle tool nélkül is. Ezzel nem is fogok vitába szállni, mert ez így igaz, persze más kérdés, hogy egy 160M-s XML-t ki akar "kézzel" olvasni.

Másik nyomós érv az, hogy "mert ehhez vannak eszközök". Nos, ez is egy nyomós érv, viszont egy hatalmas 22-es csapda. Főleg Unix/Linuxos körökből származnak ezek az érvek ott is leginkább azért mert a sok kicsi program legkülönfélébb kimenetét a sok kicsi másik program bemenetére össze kell celluxozni valahogy. Avagy, a probléma eredeti gyökerét vizsgálva, én szemszögömből nézve inkább egy szükségmegoldásnak tűnik, mint egy szükségmegoldásnak arra a problémakörre, amelyet maguk a textfilek generálta: ahelyett, hogy megoldották volna a programok egymás közötti kommunikációját, inkább tákoltak.

És hova vezetett ez? Napjainkban egyre több és több rendszer használ valamilyen szöveges protokolt, de nem azért, mert szemmel olvashatónak kell lenni vagy mert tényleg igény lenne arra, hogy azt sed-del, awk-val túrja valaki*, hanem csak és kizárólag két program közötti kommunikációra. Aztán mi ad isten, mi jövő? Lassú a http, legyen spdy, terjengős az XML, legyen binary XML..., sokat foglal? tömörítsük! Csodás.

Ilyenkor nagyon jó példa a régi Excel formátum: alapvetően úgy volt tervezve, hogy a fájl egyes blokkjai egy az egyben írhatóak/olvashatóak memóriába mert gyakorlatilag a struct-ok voltak kiírva egy nagy egészben. Ezzel szemben ma mi van? XML fájl megnyit, DTD/XSD validálás, utána értékek validálása (törtszámok, jaj...) majd abból struktúra felépítése és vissza. Ezen az se segítene sokat, ha XML helyett JSON lenne.

Vagy a másik csodás példa, Wavefront object. Ha bináris lenne, sok esetben egy az egyben egy nagy blokk olvasással be lehetne tölteni és mindenféle konvergálgatások helyett akár egyből pl. OpenGL-nek átadni. Ilyenkor nekem kétségeim vannak arról, hogy valójában melyik megoldás is az egyszerűbb.

Persze, az az érv még mindig megvan, hogy mert nincsenek hozzá jó eszközök. Ez tény, de szerintem a fő hátráltató erő ezen eszközök ellen az a text toolok csapdája: mert azért választanak sima szöveget, mert a binárishoz úgy sincs eszköz.

* Arról nem is beszélve, hogy mennyien meglepődnek, hogy a CSV-ben egy string lehet többsorú is, ami miatt nem lehet \n mentén szétválasztani. Erre szoktam mondani, hogy "aki explode-t használ egy CSV parseolására, sikeres ember nem lehet". És akkor még nem is beszéltünk a különféle nyelvek közötti különbségről. Aki dolgozott már fel németek által készített XML-t vagy CSV-t, az tudja miről beszélek. :)

( sj | 2013. 04. 29., h – 23:04 )

-1

ha nem tetszik egy protokoll, szabad helyette ujat csinalni. Senki nem fogja le a kezed, ha pl. a http-ng-be vagod a fejszedet.

egy 160M-s XML-t ki akegy 160M-s XML-t ki akar "kézzel" olvasni.ar "kézzel" olvasni.

passz. De mondjuk logokat szeretek inkabb a tail|*grep komboval nezegetni, mintsem valamilyen "tool"-lal.

a sok kicsi másik program bemenetére össze kell celluxoz a sok kicsi másik program bemenetére össze kell celluxozni [...] inkább egy szükségmegoldásnak tűnik, mint egy szükségmegoldásnak arra a problémakörre, amelyet maguk a textfilek generálta: ahelyett, hogy megoldották volna a programok egymás közötti kommunikációját, inkább tákoltak.

itt valoszinuleg lemaradtal az ivrol. A programok sok esetben a stdio/stdout kombon keresztul kommunikalnak (meg idonkent syslog()-olnak), azaz nagyon jol ki lett az egymas kozti kommunikacio talalva, nincs ebben hiba*. Aztan ahelyett, hogy minden egy ...king problemara lenne egy bohom tool, ami btw. kezelhetetlen lenne, inkabb van kevesebb, de altalanosabb tool, amiket egymas moge pakolva (pl. pipe) egesz impressziv dolgokat muvelhetsz. Igy a "celluxozas" mondjuk egy shell script a feladatra

*: azt meg senki nem tiltja meg, hogy az stdout-ra egy binaris cuccot hanyjon ki a program, amit a moge tett program2 igy olvas be a stdin-rol.

Egy kicsit az is a fud-szagot erositi, egyszer szoveges protokollokrol beszelsz, majd unix alapparancsokrol, majd az excel-re (es formatumara) valtasz, hogy milyen jo is volt regen.

a CSV-ben egy string a CSV-ben egy string lehet többsorú is, ami miatt nem lehet \n mentén szétválasztani. lehet többsorú is, ami miatt nem lehet \n mentén szétválasztani.

mi general ilyet? Azon tul, hogy bottal utnem agyon a keszitojet, mert "CSV" is not a single, well-defined format...

Diktatorok kezikonyve

A unixos shellel az a baj, hogy minden objektumot (oké, struktúrát) szerializálni kell, majd a másik oldalon deszerializálni. Ha binárisként történik, akkor is ronda és sok hibalehetőséget hordoz, textként csak rosszabb a helyzet. Csak hogy egy viccesebbet említsek, ldif-ben lehetőség van egy sort tetszőleges ponton megtörni, ekkor a következő sor első karaktere space kell legyen. Nem mondom, hogy lehetetlen feladat ehhez parsert írni, de aki ezt kitalálta az mégis mit szívott?

Érdekes módon powershellben meg tudták oldani, hogy legyen pipe, ne legyen szerializáció és deszerializáció és legyenek általános cmdletek amikkel tetszőleges típusú objektumokat fel lehet dolgozni.

Szerk: oké, itt egy picit más történik mert csak referenciák utaznak a pipeban, nyilván két process között ez nem megoldható. De a működéséhez szükséges, hogy ne csak adataink legyenek, hanem metaadataink is, és amíg mindkét oldal ismeri a metaadatokat, addig az adatok feldolgozásával sem lesz gondja, legyen az akármilyen formában.

"mi general ilyet? Azon tul, hogy bottal utnem agyon a keszitojet, mert "CSV" is not a single, well-defined format..."

Azért RFC van rá, ami definiálja mi a teendő ha sortörést szeretnél.

Az a néhány évtizedes korkülönbség ugyanennyi éves tapasztalatok felhalmozódását is jelenti. Anno nem volt bőségesen memória, amiben összetett struktúrákat lehetett átadogatni folyamatok között, a programok vagy a másik bemenetére vagy a sornyomtatóra vagy fájlba (amit egy másik program olvasott fel) dolgoztak, amit ha egységesen akartak kezelni, az olvasható szöveges formátum adta magát.

A PowerShell (nagyon egyszerűsítve) "objektumok a csőben" módszere ezen lépett túl.

"mi general ilyet?"

Kb. minden, ami ismeri a CSV formátumot. http://www.creativyst.com/Doc/Articles/CSV/CSV01.htm

Hja és az ilyen hozzáállás miatt "élmény" a CSV-k feldolgozása, mert hol így hol úgy hol amúgy néz ki, aztán mivel mindenki próbálja meginnoválni, totál figyelmen kívül hagyja, hogy mik lehetnek a kivételek. Pl. megokosítja valaki, hogy ; legyen, mert terméknevekben van ,. Hja, aztán jön egy ; és egy újsor is a terméknévben, mert a kedves termékfeltöltő kolléga nem gondolt rá az okostóni, aki meg a CSV-t kifaragta szintén szart bele, hogy létezik egy szabvány.

" A programok sok esetben a stdio/stdout kombon keresztul kommunikalnak"

Remek, már ezer éve látszik ennek a megoldásnak a hátrányai.

"Egy kicsit az is a fud-szagot erositi, egyszer szoveges protokollokrol beszelsz, majd unix alapparancsokrol, majd az excel-re (es formatumara) valtasz, hogy milyen jo is volt regen."

Mivel mindenhol terjed ez a nézőpont.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mert szöveges input-output eseten nem egy struktúrát kapsz, hanem egy karakterkupacot, amit foleg az egekig magasztalt unixokon megtoldva a nyalvfuggoseg minden nyugjevel egyutt ugy kell osszecelluxozni.

Erre amugy nagyon jo pelda a picivel odébb linkelt cikk a Plain text vs. Xml-es java exception logrol.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

fentebb irtam, hogy a stdin/-out-on vigan lehet binaris adatokat is kuldozgetni, szoval meg mindig nem latom, hogyan fugg ossze az "osszecelluxozas" a "text hell"-lel...

Arrol meg hallgassunk egyelore szemermesen, hogy a "struktura" eroltetese nem minden felhasznalas eseten ertelmes csapasirany...

Diktatorok kezikonyve

fentebb irtam, hogy a stdin/-out-on vigan lehet binaris adatokat is kuldozgetni, szoval meg mindig nem latom, hogyan fugg ossze az "osszecelluxozas" a "text hell"-lel...

Itt nem arról van szó hogy szöveges vagy bináris adatfolyamokon keresztül kommunikálnak egymással a programok, hanem arról hogy strukturálatlan adatokat küldözgetnek egymásnak. Amúgy ezt előttem már BaT is megfogalmazta, csak el kellett volna olvasnod a hozzászólását. Remélem nem gond, ha tőle idézek: "A unixos shellel az a baj, hogy minden objektumot (oké, struktúrát) szerializálni kell, majd a másik oldalon deszerializálni. Ha binárisként történik, akkor is ronda és sok hibalehetőséget hordoz, textként csak rosszabb a helyzet."

Próbálj meg dátumot vagy törtszámot feldolgozni a területi beállításoknak megfelelően.

(Ilyenkor eszembe jut, hogy egyesek azon hőbörögnek, hogy .NET-ben miért tették alapértelmezettnek a területi beállításokat a Valami.Parse() -nak...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azert egy tobbgigas adathalmazt akkor is nehez kezelni ha binaris formatumban van, meg akkor is, ha szovegesen. A szovegesnek viszont megvan az az elonye (foleg az emlitett logoknal) hogy nem kell a stukturat felepiteni ahhoz, hogy ertelmezheto legyen.

Logra biztos, hogy a plaintext az egyik legjobb. Vegulis azt elsosorban pont olvasni fogjak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Az semmi. greppeltem en mar tizgigas logban is, nem mondom, hogy nem tartott el egy darabig, de mukodott. De ha azt veszem, egy hasonlo meretu binaris logban kereses ugyanolyan lassu, mar csak azert is, mert fel kell olvasni a diszkrol a logot, marpedig altalaban ez szokott a szuk keresztmetszet lenni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

n*10G logban grep-pel keresni... Ad-hoz tákoldához jó lehet, de ha napi sok ilyen kérés/kérdés van mondjuk a több ezer darabos eszközpark (hw/sw) logjaira vonatkozóan, akkor azokat bizony illendő értelmes adatbázisba belapátolni, megfelelően parse-olva és tokenizálva/cimkézve. Bináris adathalmaz, a szükséges indexekkel - és máris nem kell szekvenciálisan végignyalni az n*10G adatot...

Hat az a problema, hogy altalaban nem szokott gond lenni, de ha van, akkor bizony szep nagy logokat kell atnezni, akar 1-1 webappra vonatkozoan is.

Az adatbazisba logolassal az a problemam, hogy eddig nem talaltam olyan komplett megoldast, ami ertelmesen mukodne is, es gyorsan is lehetne benne keresni. Amiben jol lehet keresni az egy ido utan nem bir a logokkal, ami meg birna a logokat, abban meg iszonyu lassu a kereses. Pedig mindketto fontos szempont lenne, mert ha hosszu percekig kell neznem a homokorat a keresesnel, akkor nem vagyok elorebb a greppelesnel, legfeljebb mindezt egy szofisztikalt interfeszen keresztul teszem meg.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

De, persze. Viszont a beolvasas mindket esetben fix idokonstans, amit en sugallni akartam, az az, hogy a regularis kifejezes applikalasa vs struktura felepitese kozott nem felteltetlen van szamottevo differencia, foleg, hogy mindket modszernek elsosorban az ertelmezni valo adatra kell varnia. Mas lenne a helyzet, ha az adat mar a memoriaban lenne, ekkor valoszinuleg a regularis kifejezes lassabb.

Az viszont igaz, hogy ha mindez indexelve van (a binaris log lehetove tenne) akkor a kereses gyorsabb is lehet, viszont ennek meg az a hatranya, hogy egyreszt nagy lehet az index (hiszen egy lognal nem lehet elore tudni, hogy mire akarunk keresni, kovetkezeskepp a fontosabb mezoket indexelni kell, ennek resze az uzenet maga is), masreszt hibalehetoseg forrasa, hiszen ha egy ilyen binaris adathalmaz kezeloje barmiert nem mukodik, akkor a loggal semmit nem lehet kezdeni, csak egy blob a diszken.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Hat nem tudom, logolasnal az szempont, hogy minel kevesebb hibalehetoseg legyen magaban a logolasi folyamatban (a nyilvanvalo hibakat, diszk beteles, read only diszk leszamitva), es en az indexelesben hibalehetoseget latok. Esetleg utolagos indexeles - de ez meg nem biztos, hogy segit akkor es ott.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( kmARC v | 2013. 04. 29., h – 23:11 )

> "aki explode-t használ egy CSV parseolására, sikeres ember nem lehet"
Szerintem sem lehet sikeres aki explode-ot használ, az php-s.

Amúgy való igaz, én sem értek egyet a pazarló fájlformátumokkal, amiket a kutya sem fog "kézzel" olvasni, csak a megjelenítővel. Nyilván logokban grepelni más.

( BaT | 2013. 04. 30., k – 00:52 )

"Másik nyomós érv az, hogy "mert ehhez vannak eszközök"."

Telkósokat kell megkérdezni, milyen eszközeik vannak a bináris protokolljaikhoz. Pl. leírásukra ott az ASN.1.

Szófosásom van, hadd pofázzak még egy kicsit. :)

A szöveges formátumok lényege, hogy a metaadat is az adattal együtt utazik. Pl. xml esetén az xml struktúra a metaadat. Ezért könnyebb toolok nélkül debuggolni, ezért lehet egy általános parserrel bármilyen ugyanolyan formátumú adatot feldolgozni, stb., és ezért lesz a kommunikációs overhead nagy. Ehhez csak az kell, hogy a parser ismerje a használt formátum leírását, vagyis a meta-metaadatot. Bináris formátumok esetén már a metaadatot is ismernie kell a parsernek. Viszont miért ne lehetne ezt a metaadatot egy szabványosított úton menet közben megosztani, vagyis lehetővé tenni hogy egy általános parser tetszőleges formátumú (akár bináris) adatot fel tudjon dolgozni, miután megkapta az ahhoz szükséges metaadatokat? Biztos vagyok benne, hogy vannak ilyen protokollok, igaz rákeresve csak a ws-metadataexchange jött szembe ami picit más.

"A szöveges formátumok lényege, hogy a metaadat is az adattal együtt utazik. Pl. xml esetén az xml struktúra a metaadat."

De épp ez az, hogy arra meg ott lenne a DTD/XSD, ami már nem biztos, hogy együtt utazik. Mert ugye ki fogja validálni, hogy valóban olyan formátumban jöttek-e az adatok, mint ahogy? Egyébként pont ez a felosztás lenne olyan, ami jól serializálható binárisan: van egy leíró a formátumhoz, amire hivatkozni kell és van maga az adat binárisan, salangmentesen. De valami ilyesmi van az ASN.1-nél is.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( Nyosigomboc v | 2013. 04. 30., k – 00:22 )

Amit a MS az Excellel (meg az Office tobbi reszevel) eloadott, az a tipikus peldaja annak, hogy hogyan ne!
Ha binaris strukturakat kepezel le 1:1 modon a fileformatumodban, akkor kapsz egy - teszemazt - excel 5.0-as file-t. Ha fejlesztesz rajta, akkor a strukturaidat idonkent kiegeszited, kapsz egy kovetkezo valtozatot. Ha az uj excellel az osszes addigi excel formatumot meg akarod nyitni, akkor kell az elejere egy info (verzio), es az osszes strukturalekepzest bele kell irnod az ujba (amitol bonyolultabb is lesz, mint az XML-alapu). Kulso programmal lehetetlen feldolgozni, pedig eleg sokszor jo lenne/jo lett volna illeszteni valami belso fejlesztesu toolhoz. Ha megis megirod a kulso toolod xls feldolgozasat, a kovetkezo verzional kovetned kell, akkor is, ha szamodra lenyegtelen dolog modosult.
A kulonbozo verzioju .xls/.doc kezelese egyebkent a keszitoknek sem ment, idonkent total hulyeseget kepes importalni.
Idovel a sok (altalaban kikapcsolt) feature-tol a strukturaid nagyok lesznek, de akkor is le kell tarolnod, hogy ez itt epp ki van kapcsolva. Egy xml-bol siman kihagyhatnad az adott attributumot. Tomoritett XML eseten joval kisebb helyet fog foglalni az eredmeny, mint ha siman kihanytad volna a strukturaidat a lemezre.
Egyebkent nem veletlen, hogy a MS is atallt erre.

Ha 2 kulon fejlesztesu program kozti kommunikaciojarol van szo, akkor mindenkepp erdemes megfontolni a dolgot.
A HTML-nel is vannak pl. megjelenitesbeli kulonbsegek (sokfele bongeszo, sok render engine), binarisan ez teljesen mukodeskeptelen lenne.

Persze annak is van elonye, pl. raszteres kepek, filmek eseten nem hiszem, hogy az XML/JSON/egyeb szoveges levaltana valaha a binarist (max. kiegeszitheti a meta-infoknal).

szerk:
eloturtam a temahoz illo linket:
http://www.joelonsoftware.com/items/2008/02/19.html

--
The programmers of tomorrow are the wizards of the future. You know, you're going to look like you have magic powers compared to everybody else. -Gabe Newell

"Persze annak is van elonye, pl. raszteres kepek, filmek eseten nem hiszem, hogy az XML/JSON/egyeb szoveges levaltana valaha a binarist (max. kiegeszitheti a meta-infoknal)."

Ó, már ott is terjed a rák, lásd SVG.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( locsemege v | 2013. 04. 30., k – 00:29 )

Akkora -1, hogy inkább -2. A bináris formátummal az a baj, hogy ha van hozzá eszközöd, doksid, akkor jó, ha meg nincs, akkor ígyjárás van. Textes formátum esetén pedig megnézed a file-t, s a speciális igényedre írsz egy scriptet, s készen vagy. Ne feledd, lehet, hogy azért nincs eszközöd a feladatra, mert a felhasználók azon 0.0001 %-át alkotod, akinek olyan nyakatekert dolgot kell megoldania, de azonnal, amire senki sem gondolt, a fejlesztő sem esetleg.

Ezen felül text formátum esetén könnyebb debugolni, létező hibára annak megkerülésével workaround-ot adni. Bináris formátumnál vagy minden jó, vagy pislog az ember, hogy most akkor mi van. Textet még esetleg összerakja az ember, ha valamelyest összedőlt, binárist aligha.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Látom, neked sem jött át: az, hogy _kellene_ egyszer végre normális eszközkészlet ezekhez is, nem csak folyton tologatni a problémát, hogy mert hát a másikhoz van, inkább kókányoljunk azzal. Nagy kár, hogy az informatika abba a korba ért, hogy lehet nyugodtan pazarolni az erőforrásokat.

De valószínűleg csak nekem kellett már túl sok időt elbasznom arra, hogy különféle text based szarokat egymáshoz tákoljak, ahelyett, hogy valami struktúrában utazott volna és a végeredményben is valami struktúrát kaptam volna és ne nekem kelljen kézzel felépíteni azt.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( uzsolt v | 2013. 04. 30., k – 08:09 )

Szerintem a kettő között van az (i)gazság.
Logfájlok esetén szerintem is praktikus a szövegformátum, hiszen bármi csúnya dolog is történik, őket könnyebb kezelni.
Sok esetben a bináris jobb, pl. egy képet is érdemesebb abban tárolni, meg persze kisebb helyet is foglal (ami még a mai világban is számít, akár a net miatt, akár a családi fotók tárolása miatt).
Dokumentumok esetén speciel inkább egy "leíró-nyelvet" preferálok, mint az állandóan változó bináris formátumot - LaTeX-hel még sose akadtak olyan gondjaim, mint word(-szerű) dokumentumokkal, szinte mindenhol ugyanúgy néz ki, nem függ a géptől, hogy hol ér véget egy oldal, stb.
Viszont egy json-ban küldött adathalmazt is könnyebb debuggolni, mint egy binárist (kezdőként azért jártam úgy, hogy az egyik függvényt hibásan használtam, sose jött az ki, amire számítottam, utána "simán" megnéztem, és rájöttem, mit csesztem el).

Szóval mindkettőnek van létjogosultsága, a saját területén, illetve a feladattól függően.

Valóban nem, nem is úgy akartam írni, utólag elolvasva viszont már valóban érthető úgy.

Szóval amit mondani akartam, hogy maga a latex-forrás egészen jól hordozható, és (dvi-be, pdf-be) lefordítva minden gépen ugyanúgy jelenik meg (persze nyilván a szükséges feltételek megléte esetén). Míg a wysiwyg-jellegű szerkesztők esetében ugyanaz a doksi ugyanolyan verzió "olvasóval" más gépen máshogy jelenik meg. És (értelmesen) semmit nem tudsz ezzel kezdeni. Latex-ben viszont a szerkezet (aki tudja olvasni) jól követhető, nem érnek meglepetések. És még egy fontos dolog: 10-20 évvel ezelőtti doksikat is ugyanolyan jól tudsz kezelni, mint 10-20 évvel (mondjuk persze ez nem text/binary war, inkább a lefektetett szabályok kérdése).

A (La)TeX-ben kicsi az esély arra, hogy az alapértelmezett formázásokat, stílusfájlokat átvakarja valaki, de előfordulhat, viszont plédául a WinWord esetében a normal.dot az anno ahány gép, annyi féle lehetett - ami a kapott doksi megjelenítésére is komoly hatással bírhatott.

A formátum időtállósága az jó kérdés - leírás alapján, vagy meglévő forráskódból bármilyen formátumra írható parser/megjelenítő, az viszont igaz, hogy a szöveges alapúakból a releváns információt könnyebb kinyerni. (Lásd régi saját formátumokat folyamatosan dobálják ki az Office csomagokból - lassan jó üzlet lesz az ilyen régi formátumú fájlok konverziójába befektetni :-D)

( sh4d0w808 | 2013. 04. 30., k – 08:52 )

Az excel említése külön azért jó, mert ekletáns példája annak, mennyi felesleges információt hány a végeredménybe az alkalmazás, ha rosszul van megírva.

-------------------------
Trust is a weakness...

( saabi v | 2013. 04. 30., k – 08:52 )

So-so. Amit az XML-ről írsz, azzal egyetértek, ritka elbaszott egy formátum és úgy pazarolja a helyet ahogy semmi más. Ugyanakkor normális konfigurációs file-ok esetében nagy könnyebbség, ha az text alapú. Mondjuk nekem egy több tíz kilobyte méretű konfigurációs file már több mint gyanús. Kivéve ha kommentek vannak benne, az tényleg viszi a byte-okat. Az standard ki- és bemeneteken nem csak szöveges adatok áramolhatnak át, ezt a részét nem igazán értettem az írásodnak.

Ave, Saabi.

( carlcolt | 2013. 04. 30., k – 10:31 )

A dolgok nagy részében nem értek veled egyet, de valamivel igen. Oké, hogy te olyan hiperzseni vagy, hogy binárisan is ugyanolyan gyorsan dolgozol fel mindent, mintha szöveg lenne, meg fejből tudod a csv specifikációját, nem csak következtetsz abból, hogy az Excel új sor katakter esetén új sort ír, de attól még jóérzésű programozó, aki tudja, hogy más nálad kevésbé zseniális programozók is dolgonzak a projekten felfogja, hogy:
-nem mindenki olvassa hexában az objektumokat úgy, mintha egy magyar nyelvű szépirodalmi könyv lenne
-csv-t csak olyan helyre választ már a tervezéskor is, ahol biztos hogy nem lesz új sor tárolva

Ahol van egy interfész az objektumokhoz, ott nyilván azt kell használni, odáig értem a mondandódat. Gyorsabb, jobb, kevesebb a hibalehetőség (ha jól tervezték meg), stb. De nem minden program készült úgy, hogy majd a létező összes programmal együtt tudjon működni és ez még le is legyen tesztelve. Éppen ezért elvárom, hogy - legrosszabb esetre felkészülve - minden program legyen képes egyszerű picit formázott stringként is kipakolni az outputját. Arról nem is beszélve, hogy a legtöbb program emberi inputot vár mint stringet, és ember elé outputot tesz, mint stringet. Addig oké, hogy egy normálisan megírt program csak onnantól kezd el stringgel dolgozni, amikor már az outputhoz vagy az inputhoz közvetlenül kapcsolódik. Stringnek máshol ugyanis a kódban helye nincs. Viszont azt hadd várjam már el, hogy stringként adjon outputot mindenről, amire szükségem lehet, ha mást egyszer nem sikerült, és én majd átadom valaminek ahogy akarom, valahogy ahogy én akarom, lehet szívok vele kicsit, az én felelősségem, legalább egy ilyen lehetőség volt. Csak ha már építkezek valamire, akkor olyanra építkezek, amire eleve tervezték a programot: userknek szánt outputokra.

A doc vs docx érved viszont nevetséges volt. Adott egy bináris dokumentum, véletlen rossz bit kerül bele pl. egy Office-ban lévő bug miatt. Hogy állítod helyre? Adott egy xml dokumentum, hibás sor kerül bele, és jéé, gyorsan megvan hogy hol a hibája.

Ami szintén nevetséges volt: a szöveg feldolgozása több számítási kapacitást igényel mint a bináris. Egyrészt, ami user input és output, azt eleve szövegből/szöveggé kell alakítani, ennek az oda-vissza dolgozására fejlődik minden évek óta, másrészt már az első Unix rendszerek idején is megérte ényegesen kisebb, maiakhoz képest nevetségesen kicsi számítási kapacitások mellett szöveget kezelni inputként és outputként, mert ért annyit a "felhasználóbarátsága". És akárhogy nézed, a Unix az egyetlen több mint 40 éve működő rendszermodell. A Windows kivételével minden versenyképes rendszer Unix alapú, vagy legalább Unix szerű. Egyszerűen az működik, több mint 40 év alatt nem tudott senki kitalálni jobbat. (Igen, tudok róla, hogy a Linux és a Xorg sok ponton nem követi a Unix filozófiát). Ja meg még valami a "binárist gyorsabb feldoglozni" marhasághoz: futtass végig egy kersést a Windows registry-n, aztán meg egy /etc mappán. A Windows registry nem csak hogy kevésbé felhasználóbarát, de brutálisan lassú is, még a plain text kereséshez képest is.

( doc | 2013. 04. 30., k – 11:53 )

nem ertek egyet (vagy ha ugy tetszik, -1)
szoveges formatumu adatokkal nagyon konnyen dolgozhatsz, lehet debugolni, konnyen megtalalod amit keresel
ha odavagok hozzad 25 KB binaris csomagot, abban talald mar meg hogy mi nem jo...
igen, a szoveges file-okhoz vannak toolok. tobbek kozott azert, mert trivialisan hasznalhatok es keszithetok
hogyan akarsz tool-t csinalni 'binaris adat'-hoz? vagy minden letezo binaris formatumhoz kulon-kulon toolok legyenek amik szoveges formatumra alakitjak?
raadasul multiplatform fejlesztesnel a binaris formatum eleg sok problemat tud felvetni (szovegesnel max. a kulonfele sorveg/karakterkodolas jelenthet problemat, de az elobbi mar eleg jol mukodik mindenhol, utobbire meg ott az UTF)

De épp ez az, hogy ki akar folyamatosan adatot debuggolni?

a) Legyen valami, amivel definiálni lehet a struktúrát (ld. XML-nél DTD, XSD).
b) Legyen lib, ami írja, olvassa ezeket a struktúrákat.
c) Legyen eszköz, ami vizualizálja ezeket az adatokat.
d) Aki nem a szabványos utat használja (és ez igaz szöveges formátumra is, ld. CSV, XML), annak le kell törni a kezét.

"raadasul multiplatform fejlesztesnel a binaris formatum eleg sok problemat tud felvetni"

Igazából egyetlen egy igazán problémás területet látok, az pedig a little/big endianing. Float szabvány, dátumnál szintén csak egy fix struktúrát kellene definiálni.

Emellett:
- hányféleképp is ábrázolnak törtszámot?
- ?SV-kben hányféle karaktert használnak szeparátornak? (Mert "vessző még előfordulhat, tab már kevésbé" -- aztán valahogy mégis jön egy tab ott, ahol nem kellene).
- Dátum leírására hányféle szabvány is van?

Karakterkódolás még a legkisebb probléma szerintem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"De épp ez az, hogy ki akar folyamatosan adatot debuggolni?"
ez nem akaras kerdese... ha valami gebasz van, debugolni kell
es lenyegesen egyszerubb mondjuk egy szoveges alapu XML-t vagy barmilyen kommunikaciot debugolni, mint egy rakat TCP csomagot

"Igazából egyetlen egy igazán problémás területet látok, az pedig a little/big endianing."

akkor mondok meg egyet: tipusok merete
ha az egyik gepen 4 byte az int, a masikon 8, akkor az eleg rendesen be tud kavarni (marmint binaris formatumnal, ha szovegesen irod ki, akkor teljesen mindegy hogy mekkora, ott max. az lehet a gond ha tul kicsi es nem fer bele aminek kene)

"ez nem akaras kerdese..."

Erre roppant jó példa a SOAP, ha normálisan használják: nem érdekel, hogy milyen WSDL/XML kódot generál a service, nem érdekel, hogy a kliens mit generál, én a két oldalt csak és kizárólag objektumokat látok. Akármilyen nyelvről is van szó. (Probléma a SOAP-pal is ott kezdődik, mikor valaki okosba akarja tolni...)

Ugyanígy nem értem, miért is kellene újra feltalálni az adatok kiírását, visszaolvasását, ahelyett, hogy egy szabványos, jól kitesztelt liben keresztül használnánk mindent.

Fájlrendszert sem kezded leellenőrizni nulláról, csak mert ráírtál egy fájlt.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"es lenyegesen egyszerubb mondjuk egy szoveges alapu XML-t vagy barmilyen kommunikaciot debugolni, mint egy rakat TCP csomagot"

Xml-t sem notepadban debuggolsz, arra is minimum olyan programot használsz, ami szépen színezi a doksit. Jobb esetben lehet csukogatni a tageket, megjeleníti a dokumentum fát, figyelmeztet a szintaktikai hibákra, vagy meg lehet neki adni a DTD/XSD-t és az alapján validálja is.

Ha pedig xml-re lehet ilyen eszközt írni, akkor binárisra is. Mondjuk megadod neki az adatformátum leírását, az szépen színezi neked a hexa outputot, stringeket, számokat emberi formátumban is megjeleníti, stb.

"akkor mondok meg egyet: tipusok merete"

Ez kb. olyan hiba, mint szintaktikailag hibás xml-t generálni (endianness meg kb. a hibás kódolású xml). Amikor specifikálod a bináris formátumot, akkor nem azt adod meg hogy int, hanem hogy int32 és meg is van oldva a probléma.

A binaris problemanal en pont ezeket az "okosba" megoldo embereket latom hatranyanak. Minden eszkozt lehet rosszul hasznalni, ezt is, de a binaris formatumnal - pont azert mert binaris - nagyon nehez kitalalni, hogy hol nem kovette valaki a protokollt. Nincs meg a lehetoseged arra, hogy menet kozben igazits egy kicsit a dolgokon, mert a binaris formatumnal, ha valami elcsuszik, adott esetben a komplett struktura kuka lesz, semmi ertelmes adat nem nyerheto ki belole. Es valahogy nem vicces hexaeditorral turkalni.

Es ezen nem biztos, hogy akarmilyen eszkoz tud segiteni, mert egy binaris formatumot nem lehet "maskepp" ertelmezni. Itt arra gondolok, hogy peldaul egy XML-nel, ha valamit nagyon nem sikerul beparzolni, akkor a hibauzenetbe bele tudom rakni, hogy mely sorok kozt akadtak gondjaim, tehat lejjebb tudok menni egy szintet az ertelmezesben ahhoz, hogy hibat tudjak kiirni. Egy binarisnal nem segitseg, ha berakok egy husz-negyvenbajtos kornyezetet, hogy hat valahol itt volt a hiba. Raadasul nem is trivialis megmondani, hogy hol csuszott szet az egesz, blokkszinten lehet ilyet, de a blokkon belul mar semmit, hiszen a blokkot egyben nem sikerult ertelmezni. Max checksum errorokbol lehet ertelmesen kijonni.

Mig peldaul egy CSV vagy XML feldolgozasanal tudom azt mondani, hogy a negyvenotos sorral az a problemam, hogy kettovel tobb oszlop van benne, mint kellene. Tehat at tudok valtnai egy masik perspektivaba is a kotott formatum feldolgozason kivul.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Latom, te is keptelen vagy elszakadni attol az ostobasagtol, hogy *SZABVANYOS* eszkozokkel, jol kitesztelt libeken keresztul dolgozunk es nem csak fossuk bele az adatot a vakvilagba. Mi a retek az, hogy elcsuszik? Mi a retek az, hogy valami bit nem jo? Mi az, hogy maskepp ertelmezni? Ertelmezes szempontjabol kurvamindegy, hogy text vagy binaris: oda van irva, le van specifikalva (khm.), ugy kell ertelmezni, ahogy a szabvany szol.

Ha ilyen problemak felmerulnek, felmerulhetnek hogy "elcsuszik", az tipikusan jele annak, hogy valami ordenale nagy ganyolas van a rendszerben. Vagy szimplan ostoba hulye, aki tervezi a rendszert. Es ha binarisnal fel fog merulni, akkor textnel is.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Miért érzem azt, hogy álmodtál magadnak egy ideális világot ott az üveghegyen is túl, ahol a kurtafarkú kismalac túr? Mert tapasztalatom inkább az, hogy van egy probléma, amit meg kell iziben oldani, specifikáció olyan szinten sincs, hogy még talán a rendszer nevét sem tudod, amiben turkálsz, s ha text file-t látok, megkönnyebbülök, mert ránézésre kitalálom, hogyan nyerem ki belőle az infót, írok rá egy scriptet, s készen vagyok. Ezzel szemben egy bináris file-lal eléggé meg vagyok lőve. Továbbá textet platformfüggetlenül fel tudok dolgozni, a bináris file-hoz meg lehet, az egyik platformra van eszköz, a másikra meg nincs. Textet megetetek awk-val, bash-sel, bármivel, ezzel szemben, ha van egy binárisom, s ahhoz akár egy dll-em, akkor mi a fenét kezdek vele, ha van előttem egy linuxos gép? Értem én, ha programozó vagy, nálad a fejlesztői környezet, specifikáció, fűszoknyás lányok legyezgetnek, s hozzák az üdítőket, minden feltétel optimális, akkor király dolog a bináris formátum, ám az élet nem ilyen, vagy csak engem nem kímélt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ja értem, azért mert szar van, inkább túrjuk tovább, ahelyett, hogy csinálnánk valamit jól.

Ez a nézet vezet oda, hogy nem egy emberrel van a sokadik levélváltásom, hogy tanuljon már meg normálisan XML-t generálni, mert nem fogom kézzel fixálni, csak mert képtelen a szabványos eszközét használni. És akkor még szó nem volt arról, hogy bináris legyen.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Látom, nem igazán akarod érteni, hogy nem rajtad vagy rajtam múlnak a körülmények. Olyan ez, hogy ha szervizelni kell valamit, s annak egyszerű felépítése miatt egy csavarhúzóval, forrasztópákával, tranzisztorral a kezedben meg tudod oldani, akkor rendben vagy. Ezzel szemben, ha mindenféle nagyon egyedi eszközöket igénylő, egyszer használatos cuccokkal van tele az egész, esélyed sincs megjavítani a dolgot. Igen, ebben az esetben lehet mondani, az előbbi készülék elavultabbnak tűnik, de javítható, megjavítod, az ügyfél meg elégedett, mert nem azt mondod neki, hogy dobja ki, vegyen másikat, mert ez már javíthatatlan.

Különben konkrét feladatom volt nemrég, statisztikát kellett csinálnom úgy, hogy a csupasz fenekemen kívül a szerveren található adatok álltak a rendelkezésemre, dokumentáció semmi. Szerencsére textes állományokból ki tudtam nyerni awk-val, ami kellett, bináris állomány esetében annyit tudtam volna mondani, a feladatot nem tudom rövidesen megoldani, de félő, hosszasan sem, mivel az adott rendszernek nincs interface-e, eszköze ehhez a dologhoz. Az csak hab a tortán, hogy ez nem szoftverfejlesztő cég, így fejlesztői környezet sincs.

Mondom, elmélet vs. gyakorlat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ja, még valami. Tekintsd úgy, hogy a text egy mindenki számára érthető, mindennel kompatibilis formátum, amelyre elég gyorsan bármilyen speciális eszköz készíthető szükség esetén. A bináris formátum ezzel szemben csak az adott rendszeren belül értelmes, semmivel sem kompatibilis dolog, amihez vagy van eszközöd, vagy nincs, s ha éppen nincs, akkor pofára esés van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az a baj, hogy te abból tudsz kiindulni, hogy nem kapsz specifikációt és akkor milyen jó hogy text, mert legalább magadtól rá tudsz jönni. Ugyanakkor ha binárist használtak volna, rákényszerülnek a specifikálásra, te meg mondhatod, hogy specifikáció nélkül nem is nyúlsz hozzá.

Arról nem is beszélve, hogy textfile esetén is ugyanúgy reverse engineering, ha formátum specifikáció nélkül áll neki valaki "példafájlok" alapján feldolgozni valamit. Másrészt közel sem biztos, hogy ami a példafájlban szerepel, az alapján minden feature kiderül. Olyan ez, mintha valaki egy honlap HTML kódja alapján próbálna megtanulni a webfejlesztést.

Szóval az alapvető probléma itt nem az, hogy a bináris nem olvasható "szemmel" (egyébként meglehetősen sok formátum meglepően egyszerű), hanem, hogy próbáljuk elodázni a specifikáció hiányát azzal, hogy ja, hát úgy is textfájl... Na ez az igazi probléma.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ideális esetben ez megy. Ugyanakkor az élet olyan, hogy mindegy hogyan, de meg kellene oldani a problémát most. Ha úgy csinálunk sakkozó automatát, hogy egy jól sakkozó kollégát teszünk a dobozba, amíg a végleges változat elkészül, akkor úgyis jó.

Szóval örülj neki, hogy ideális körülmények között dolgozhatsz, de ez közel sincs mindig így. Olyan is van, hogy belső használatra kell hamar valami, az sem baj, ha nem általános, az sem baj, ha hiba van benne, mert becsléshez kell. Nem minden eladásra készül. Ezt nem vagytok hajlandók megérteni. Más a laborkörülmények közti, idealizált világ, s más a hétköznapok szögelős, kiékelős, betapasztós valósága.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Most azert elegge mellelottel, mert nem eladásra fejlesztek, hanem belülre, illetve a fő kereskedelmi tevékenységet elősegítő szolgáltatásokat (legyen az b2b vagy b2c). Szerintem egy eleg tetemes idő jonne ki, ha osszeszamolnam, hogy mennyi felesleges munkám volt azert, amiert a szabványos út helyett egyedi, zömében szar megoldásokhoz kellett alkalmazkodni es/vagy szívni azzal, hogy az "okosba" gyorsban összetákolt szarokat kesobb egy normális megoldásra cseréljem. (Jellemzően többszörös költséggel, es akkor nem beszéltünk meg a rossz ganyolmany okozta anyagi es presztízsveszteségről.

Igen, az informatikának nagy rákfenéje, hogy lassú és lassan képes reagálni az adhoc igényekre (ebben benne van az is, hogy rengeteg mindenre nincs szabvany, amire meg van, azt sokan nem ismerik es inkabb kokanyolnak helyette valamit), de ezen nem segít az, hogy a barkács-szakkörödet promotálod.

---------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Értem. Tehát, ha valamire nincs konyhakész, szabványos megoldás, semmiképp se oldjuk meg a problémát, mégha képesek is vagyunk rá. Minek. Csak kész modulok szabvány szerinti konfigurációját engedhetjük meg magunknak, bármi, ami ettől eltér, tilos.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, viszont ez szubjektív elemeket tartalmaz. Van a feladat, ennek megoldásához keres utat az ember. Ha megvan az út, akkor ahhoz keres eszközt. Ugyanakkor választhatok saját utat is, ugyanis hosszas dokumentáció olvasás, licensz nézegetés, vásárlás helyett lehet, hogy két nap alatt megoldom egyedileg a dolgot, s még azt is érteni fogom, hogyan működik.

A kész megoldások rákfenéje, hogy sok esetben nagyon általánosak, egy rakás fölösleges dolgon kell átrágnia magát az embernek, hogy azt a kis részt használja, amire szüksége van belőle. Ráadásul lehet, amire nekem kell, nem a legalkalmasabb az eszköz.

Teszem azt, nem muszáj mindenhova oprendszert tenni egy rakás könyvtárral, kernellel, alkalmazással, ha sokkal egyszerűbb a feladatot egy mikrokontrollerrel megoldani, s arra egyedi célprogramot írni mondjuk assemblyben.

Úgy gondolom, az értelmezés kérdése, mit nevezünk tákolásnak. Van a probléma, megoldja az ember. Kitalálja, hogyan. Ha tervezel egy dobozt, s torx csavarral rögzíted az elemeit, akkor vajon tákoltál, vagy akkor tákolsz, ha kereszthornyú csavarokat használsz?

Szerintem az eszköz, a módszer csak döntés kérdése. Azt kell választani, amelyik mellett az adott cél elérése érdekében a peremfeltételek ismeretében több érv szól.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Dacr (nem ellenőrzött) | 2013. 04. 30., k – 14:03 )

Egy stdout-ra hajtott üzenetnél időnként tényleg jól jönne, ha valami szabványa lenne.
Jó az úgy textként, de valami rendezettséget tényleg lehetne vinni bele. Teszem azt egy commandline programot meghívok, annak a kimenete nyomna valami ilyet:


Return Code: 1
Description: Undefined index: in kutykurutty.txt on line 76
Error code: 120

Egy ilyet akár könnyebben is lehetne parseolni. Tehát ilyen tekintetben elférne egy szabványosítás.

Ja, vagy lehetne akár ilyen is:

<ReturnCode>1</ReturnCode>
<Description>Undefined index: in kutykurutty.txt on line 76</Description>
<ErrorCode>120</ErrorCore>

(Röviden: feltatláltad a melegvizet, én meg a vízforralót, a világ meg már a teánál meg a "dzsakuzi"-nál tart)

-1 a hibakódok speciális esetére. a hibakód legyen egy darab szám, aztán "én" (gy.k. a program) majd megkeresem/megkeresi, mit jelent. hülye példa: a symantec netbackup csak egyetlen darab félreérthetetlen és félreértelmezhetetlen számot okád ki nekem: az már az én felelősségem, hogy megkeressem, pontosan mi is ment mellé.

a debug az más

a hibaüzenet csak egy példa volt, de ugyanilyen elven a normál kimeneteket is lehetne rendezni. Nem csak hibaüzenetek jönnek ki, amik átadhatók egy scriptnek, ami majd kezd vele valamit. Viszont rendezettség esetén nem kell minden egyes alkalmazás esetén azt bújni, hogy vajon milyen förmedvény módon kell parse-olni, hanem egy szabványos módon megoldható volna.

( tomsolo | 2013. 04. 30., k – 17:11 )

Érdekes a kérdés, nekem erről mindig ez a jópár éves dolog jut eszembe:

good@microsoft.com

baad@m­icro­soft.com

[HINT: COPY / PASTE]

Egyébként nem tudom mekkora meló lenne megírni rá a parsert a kedves böngésző gyártóknak, hogy a kukac mentén mégiscsak megjeleníti, legalább jack és jill ne küldjön levelet/jelszót/pénzt két klikkre idegeneknek.

No rainbow, no sugar

( bAndie9100 | 2013. 05. 01., sze – 04:04 )

ultimate, kompromisszumos és egyben hardcore irányvonal a felvázolt feszültségek feloldására: olvassunk és értelmezzünk olyan magabiztosan bináris adatot, mint plaintextet!
:)

~~~~~~~~
Linux 3.2.0-0.bpo.4-486
Debian 6.0.7

de régen ez így is volt.
ránéztél a hexdumpra, tudtad, hogy a serializált objektumodnak melyik value melyik propertyje, stb.
de még ez is csakritkán kellett, mert tudtad, hogy milyen struktúrákból áll az adat, le volt specifikálva, s tudtad, hogy mit hogy kell olvasni, írni programból.

( uid_720 | 2013. 05. 02., cs – 08:24 )

Én a morgolódás helyett alkottam: az arboriumot.
Fában tudok adatot tárolni, csomópontonként adatot is és metaadatot is. A fájlformátum alapján a méretekre nincsen megkötés, de a .NET referenciaimplementáció 8 exabájtra korlátoz.

Nem akartam semmilyen típust erőltetni a felhasználóra, de adtam javaslatokat, számosat.
Elkezdtem nézegetőprogramot/szerkesztőprogramot csinálni hozzá, hogy ne kelljen érteni a binárist, de gyerek mellett elég lassan halad.

Fuszenecker_Róbert

( zamboriz v | 2013. 05. 02., cs – 09:52 )

> egyre több és több rendszer használ valamilyen szöveges protokollt, [...] csak és kizárólag két program közötti kommunikációra.

Az SQL jó példa.