ugrás a tartalomhoz

Why Flash must adopt Comet

yaanno · 2008. Okt. 3. (P), 10.40
Rövid eszmefutatás a push technológia és a flash kapcsolatáról
 ■
1

Uramatyám...

vbence · 2008. Okt. 3. (P), 10.57
Ilyet belinkelni :-/
2

Miért is?

yaanno · 2008. Okt. 3. (P), 12.00
Konkrétan mi a kifogásod ellene?
3

Válaszolok magamnak :)

yaanno · 2008. Okt. 3. (P), 12.44
A kommentek legalább olyan érdekesek, mint a felvetés - több dolgot is rendbetesznek, érdemes legalább egyszer átgondolni. Mert itt nem pusztán streamingről van szó, ami jellemzően videó, hanem egy közös (és olcsó!) platformról (comet) ami többféle klienst tud kiszolgálni adatokkal, legyen az flash v. egyéb. A szerveroldali események és adatküldés egységességéről is van szó. Szerintem ezért érdekes a felvetés.
5

Platform

vbence · 2008. Okt. 3. (P), 15.42
Én nem neveznék platformnak egy megdicsőült hekket (nyitunk két kapcsolatot a proxy felé, az egyiken egy hosszúhoszzú posztot csinálunk, a másikon egy hosszúhosszú response-t olvasunk ki), ez egyrészt csak lovaglás a fogalmakon a részemről, de ekörül a Comet körül is ugyanazt a túlhájpont légkört kezdem éretni, mint amivé az AJAX nőtt.
Eszembe jut nemrég, amikor fejlesztői képességeim felől emígyen érdeklődtek: "Milyen nyelveket használsz? Java, PHP, AJAX mennek?"
6

Hekk

yaanno · 2008. Okt. 3. (P), 16.16
Ezzel a kommenteddel kapcsolatban először is, hogy ki mit hájpol, nem tartozik egy webfejlesztéssel kapcsolatos oldal témakörébe, én legalábbis igyekszem ehhez tartani magam. Nincs királyi út - ebben megegyezhetünk.
Egy dolgot mégis: ha emlékezetem nem csal, az AJAX-ot egy böngészőben nyitva felejtett kiskapu tette lehetővé, ilyen értelemben nem is szabadna léteznie... Hekk? Az bizony, a javából.

Másrészt, a Cometet talán szerencsétlenül neveztem platformnak, rendben; mindenesetre egy választható, szabványosítható technológia lehet. Éppen ezért gondolom, hogy érdekes az írás, mert míg pl. az Adobe számára üzleti szempontból nem vonzó egy ilyen lehetőség, msáoknak igenis az lehet. És ha pl. az Adobe szakemberei mégis elgondolkodnak ezen a lehetőségen, esetleg valamilyen irányban maguk is alakítják azt, mindenki nyerhet rajta.
8

Nem vonzó

vbence · 2008. Okt. 3. (P), 16.40
A hype-pal arra akrtam utalni, hogy kicsit többet látunk ebbena dologban, mint ami van benne. (Ahogy manapság bármilyen többékevésbé aktív oldal "ajaxos", attól függetlenül, hogy valóban aszinkon-e vagy xml-t használ-e).

A commentekben utalnak rá, hogy az RTPMT protokollnál (kizárásos alapon) ezt használja a flash is.

Hogy szabványosítható technológia? Használjuk két socketet és fölösleges overhead-et egy helyett? Ki tudunk találni ennél jobb szabványt is (ahogy a négyes bejegyzés végén is gondolkodtam erről).
4

Kifogás

vbence · 2008. Okt. 3. (P), 15.30
Ez az egész cikk úgy hangzik, mint egy liboszómás arcpakolás reklámja, ami a vlóságtól teljesen elrugaszkodva bizonygatja, milyen jó is az ő terméke (és nem említi, hogy teszem azt, liboszómák nem léteznek).

Az írás ugyebár egy proxy körül forog, ami HTTP fölött meghekkelt implementációja a socketnek. Ehhez képest úgy emlegeti, mint egy szilárd megoldást bármilyen problémára.

Ha van egy örökölt ezeréves alakalmazásunk, ami valamilyen csoda folytán socketet használ, és ehhez szeretnénk most a Web2 jegyében egy aktív böngésző-beli klienst gyártani, és a nagytömegekhez eljuttatni (miért esik nehezemre elzképzelnia szituációt) használhatjuk ezt a megdolsát, majd leprogramozhatjuk az illető protokoll implementációját JSben.

Egy új projekt esetén, ahol aktív két irányú üzenetkezelés szükséges én inkább leprogramozám ezt a minimális réteget (a megfelelő nyelvben), és a saját alkalmazásomra szabnám.

Nyilvánvaló, hogy a kétirányú üzenetküldés szigorúan túlmutat a HTTP request-response alapjain. A kérdés az, hogy hekk megoldásokra szeretnénk-e építeni az új Webet, vagy inkább szabványosítani szeretnénk valamit, amivel a mai problémák orvosolhatók.
7

Reklám

yaanno · 2008. Okt. 3. (P), 16.22
Ez az egész cikk úgy hangzik, mint egy liboszómás arcpakolás reklámja

Persze hogy az :) A saját megoldását promotálja. Ezért írtam, hogy a kommentekkel együtt érdemes olvasni.
Egy új projekt esetén, ahol aktív két irányú üzenetkezelés szükséges én inkább leprogramozám ezt a minimális réteget (a megfelelő nyelvben), és a saját alkalmazásomra szabnám.

Tisztelettel felkérlek akkor erre a vállalkozásra, egy szépséges, hekkmentes megoldás létrehozására, amely implementálható "tetszőleges" nyelven, elérhető nyílt forráskód címszó alatt. A donate gombot is szívesen nyomogatnám, ha látható lenne valamilyen eredmény.
9

Lehetőségek

vbence · 2008. Okt. 3. (P), 16.47
Nem azt állítottam, hogy nekem van egy hekkmentes megoldásom. Azt mondtám, hogy leprogramoznám a megfelelő nyelvben (amiben a projekt többi részét), tehát nem egy python alapu daemon lenne kritikus része a szolgáltatásnak. Másrészt pedig én nagyjából tudnám milyen üzenetek milyen gyakorisággal, információtartalommal érekeznek, melyiknél milyen késés engedhető meg, így ahogy írtam az adott alkalmazásra lehetne szabni, hogy a lehető legtöbbet hozzon ki ebből a szerencsétlen kommunikációs rétegből.

Ahoyg a kommentelők írták, vannak erre megoldások pl Javában.
10

Csakis lehetőségek

yaanno · 2008. Okt. 3. (P), 17.16
Remélem, nem beszélünk el egymás mellett (és kissé rant szagú volt az előző kommentem, elnézést érte), ezért szeretném pontosítani, hogy Comet alatt én nem egy konkrét implementációt, hanem az általad vázolt technológiai hekket értem - az hogy az illető implementáció erlang, php, python vagy java, mellékes. Egyszóval: az implementációtól függetlenül tartanám érdekesnek a dolgot. Léteznek vacak és üzleti szférában is használt implementációk (jellemzően java alapokon), ez utóbbiak skálázhatók, monitorozhatók stb.

Az persze lehetséges, hogy egy másik protokoll megoldaná a dolgot; ám amíg nincs ilyen és nem terjedt el, építhetünk arra, amink van :)

Igazándiból engem (mivel frontendes lennék vagy mi a szösz) az érdekelt ebben, hogy teljesen különböző kliensek is kiszolgálhatók lennének ezzel (vagy más, hekkmentes) a technológiával.