Új hozzászólás Aktív témák

• #16875 Drizzt nagyúr Netszemete #16872

  Új Válasz 2021-12-11 10:43:31 #16875

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drizzt

  nagyúr

  válasz Netszemete #16872 üzenetére

  De, és a JSON nem kimondottan kis erőforrásigénnyel parse-olható formátum. Ellenben remekül olvasható. Valamint WEB API-knál megintcsak fontosabban az egyéb előnyök, mint az azokhoz elhanyagolható mértékű sebességnövelés. Könnyű olvashatóság, mindenféle architektúra könnyen tudja értelmezni.
  Ha pl. MQ-n küldesz adatot és nem akarsz parsingot alkalmazni, akkor mindkét végén a queuenak pontosan ismernie kell az adott adatstruktúrát.
  Webes APIknál általában nincsen olyan latency requirement, amiben egy +/- JSON serdes ne férne bele.
  #16873: JSON parsingnál a fő problémát az okozza, hogy nem lehet tudni az üzenet végigolvasása nélkül, hogy melyik mező hol kezdődik, így nem elég csinálni egy pár offsetről való közvetlen betöltést, ha egy mező értékét meg akarod tudni, hanem kénytelen vagy végigolvasni az eredeti JSONt(legalább addig, ahol a keresett mező(k) és annak értéke(i) van(nak)). Illetve az, hogy van szöveg, szám, meg boolean önmagában még nem segít semmit, mert a számot mindegyik oldal önkényesen értelmezheti különböző számtípusonként. Szóval általános JSON parsingnál valamiféle objektumba nem lehet megúszni a konverziót a számok esetén. Eleve a JSON sorrendfüggetlen, ugyanaz az objektum lehet a {"a": 1, "b": 2}, mint a {"b": 2, "a": 1}. Tehát nem tudsz olyat monda, hogy az Integer b mindig a 4. offseten keresendő. De még csak azt sem tudod megmondani, hogy a b Integer, Float, Double, BigInteger, BigDecimal. Szabadon értelmezhető.
  De ahol a konverzió sebessége szűk keresztmetszet, ott nem is JSONt használnak.

  I am having fun staying poor.

Új hozzászólás Aktív témák