Weblabor

A timeout szinkron esetben hogyan működik?
Például beállítok egy rövid timeoutot, amin túllóg a szerver válaszideje. Ha mégis végrehajtódik a szerveroldalon a művelet, és válaszolna, akkor a szerver válasza elvész, vagy mégis jöhet egy hívás egy callbackre?

Na jó, ez így zavaros, már olyan rég használtam szinkront ilyen esetben, hogy elsőre elfelejtettem, hogy nincs is callback. De éppen lehetne, timeout után. Vagy a timeout esetén hívódhatna meg egy callback, ami vagy lezárná a hívást, vagy tovább várna, aszerint, amit akarunk.

Na mindegy, összességében nem túl nagy lenne a nyereség, maradok az aszinkronnál, már hozzászoktam.

És mi van akkor, ha a következő használandó funkció nem fordul a hálózathoz? Nézze tétlenül a gif animációkat, mert azok legalább működnek? Szerintem inkább keres egy másik alkalmazást, ami reszponzív (ha nincs monopol helyzet; ha az van, akkor csak gondol arra, hogy lecserélné).

Én például szeretem az olyan webmail klienst, ahol miután "elküldtem" egy levelet, egyből olvashatom a korábban letöltött másik/következő levelet, vagy elkezdhetem írni rá a választ, vagy új levelet, használva az esetleg JS-t is hasznosító szerkesztőfelületet.

Felteszel sok "mi van, ha?" kérdést, és csak azokat az opciókat veszed figyelembe, amik a te álláspontodat látszanak igazolni. De minden "mi van, ha?" mellet ott van egy "mi van, ha nem?" kérdés is. Jelen esetben a te javaslatod, míg az első esetet látszólag szebben megoldja, a másikra egyáltalán nem nyújt megoldást. Én inkább azt a megközelítést választanám, ami több használati esetet megold, mert ha csak kalapácsom van, akkor csak kalapálni tudok, míg ha egy összetettebb szerszámom, akkor mást is (ehhez persze meg kell tanulni a szerszám használatát, de valamit valamiért).


Erről a Firefox ezt gondolja:

De még ha használható is lenne a timeout, az milyen felhasználói élmény, hogy ha 30 másodperc helyett 31 alatt érkezne meg a válasz, akkor dobjuk el az egészet, hogy várnom kelljen még egyszer 30 másodpercet semmittevéssel töltve, reménykedve, hogy a megengedett idő alatt ezúttal megjön a válasz, ahelyett, hogy teszem a dolgom az első 31 másodperc alatt, és kapok értesítést, hogy folytathatom azt a szálat, ami esetleg függöt tőle? Szerintem olyan, amit gondolkodás nélkül lecserélek.


Tehát örüljek annak, hogy mennek a gif animációk és esetleg tudok görgetni, de ha bármi mást szeretnék csinálni, ami JS alapú, akkor ne is álmodjak róla, mert annak úgysincs értelme, mert hátha a hálózatra vagy egyéb szekvenciális függőségre lenne hozzá szükség?
Szerintem ezt ne a nyelv/futtatókörnyezet döntse el, hanem az aktuális alkalmazás az üzleti logika alapján. Igen, ehhez az üzleti logikát szükséges a gép nyelvére lefordítani, de mintha ez lenne a munkánk.

Továbbá ismét a Firefox konzol üzenetét idézném, amit szinkron XHR hívás esetén ír:



Ennek a lónak is van egy másik oldala, ahova ha átesünk, akkor szintén a kőkorszakban maradunk.

Ez mindig nézőpont kérdése.

PHP-ban dolgozol, mert ugyanaz a feladat C++-ban sokkal több kódot igényel. A CSS és JavaScript újdonságokat viszont, amik épp azt teszik lehetővé, hogy kevesebb kóddal valósítsunk meg korábban több kódot igénylő dolgokat, meg szükségtelennek tartod, mert nélkülük is elvégezhető a feladat.

Az a baj, hogy a saját szubjektív absztrakciós szinted valamiféle objektív dolognak tartod, és ementén ítélsz meg minden technológiát. Ha már úgyis szereted az egyházi tematikájú metaforákat, inkvizícióval és eretnekekkel, akkor azt kell hogy mondjam, olyan vagy mint a bigott protestáns, aki meg van róla győződve, hogy a katolikus és az ateista is a pokolra jut.

A PHP egy rendkívül termelékeny szoftver, gyorsan lehet vele fejleszteni. Nyilván lassú és erőforrásigényes, de ezzel csak akkor kell foglalkozni, ha problémát jelent. A többdimenziós asszociatív tömbök és a szemétgyűjtés kombinációja együtt mindent ütnek.

Eleinte én is csak csendben figyeltem, hátha Liszt Ferenc. Egyrészt arra jutottam, hogy szerintem egyértelműen nem az, másrészt ha az is lenne, attól még a kortársak nem fogják (fogjuk) megérteni, tehát semmivel nem jutunk előrébb, ha hagyjuk minden témát teleprédikálni.

A másik két kategóriát meg gondolkodás nélkül moderálnám :).

A visszafele kompatibilitás azért fontos, mert egy meghatározott nyelvről van szó. A nyelvnek ismerjük a tulajdonságait, ezért arra számítunk, hogy úgy viselkedik, ahogy máshol is. Ha nem úgy működik, akkor az egy másik nyelv. És nem véletlen lett pont a JavaScript választva nyelvként a Node-hoz. Azért mert hozza azokat a szolgáltatásokat, mint a callback-ek, closure-ok, aszinkron programozás.

Ha nem akartak volna visszafele kompatibilisak lenni, akkor másik nyelvet használtak volna, mondjuk Go vagy C#, vagy pedig írhattak volna egy teljesen új nyelvet. Egyesek meg is tették, és V8 és JavaScript helyett Lua-t használnak.

De léteznek még más, Node.js-hez hasonló próbálkozások, mint a Vert.x, ami JVM alapon viszont nyelvektől függetlenül hoz egy Node.js-hez hasonló architektúrát, jelenleg Java, JavaScript, Ruby, Python, Groovy, Clojure, Scala és Ceylon támogatással.

A nyelvi elemekkel megtámogatott aszinkron lehetőségek több esetet fednek le, mintha a futtatókörnyezet döntené el helyettem, hogy az adott hívás blokkol-e, és ha igen, akkor milyen módon (ne adj isten, csak blokkoló hívások lennének). Ha a nyelvben jelezve van, hogy egy hívás milyen módon fut, akkor tudok számolni a következményeivel. Ha nincs, akkor csak reménykedhetem, hogy nem változnak meg bizonyos változóim értékei, mert a futtatókörnyezet esetleg úgy döntött, hogy csak úgy tesz, mintha blokkolna a hívás, de igazából nem.

Valamint ha ezt a döntést a környezetre bízzuk, ahogy javaslod, akkor oda a hordozhatóság. Hacsak nem vezetjük be a szabványba, hogy hogyan kell megvalósítania a környezetnek, de akkor végülis ugyanott vagyunk a szabványosítás terén, csak az egyik esetben kifejezőbb lesz a nyelv, a másikban pedig leszűkítettük magunkat egy esetre.

Persze az lenne a legjobb, ha mindenttudó lények fejlesztenék ki a programozási nyelveket, és akkor lehetne mindent az elejétől fogva jól csinálni. De ez nem opció, így marad a tapasztalatok alapján történő szabványkovácsolás.


Mikor mire. Ezért kell jelölni, hogy melyik hívás aszinkron, és melyik nem.