Uj portál protokoll
2011-08-18T07:39:37+02:00
2011-08-30T14:37:33+02:00
2022-07-24T11:42:45+02:00
  • Azaz :)
    Mutasd a teljes hozzászólást!
  • Nem nagy kaland, én pont így sexelek
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Kb a héten, vagy a múlthéten olvastam GameCloudingról.
    Az volt a lényege, hogy egy távoli szerveren fut a játék, és te csak irányítod, mintegy távoli asztal jelleggel. Sőt videó is volt róla. Brutál. Nincs telepítés, csak a képek mennek innen-oda, meg az irányítás. Generálja is az adatforgalmat rendesen, de működik.

    Szóval csak ez jutott eszembe, ez lehet egy út, egyfajta jövő.
    Mutasd a teljes hozzászólást!
  • Ezt bármikor megvalósíthatod, írsz egy szerver és egy kliens programot, a kommunikációs nyelvet meg már szépen kidolgoztad.
    Mutasd a teljes hozzászólást!
  • 1) A megszakadó kapcsolaton még nem gondolkodtam, egész pontosan csak úgy, hogy valamelyik fél szándékosan szünetelteti a futást egy munkamenet-azonosítóval. (pl. <&suspend ABCD1234)
    Ha előfordul, (és persze csakugyan előfordul) véletlenszerű megszakadás, akkor annyival fel lehet okosítani a dolgot, hogy már a legelején ad a szerver egy azonosítót, aminek birtokában a kliens folytathat egy elszakadt munkafolyamatot. (>& continue ABCD1234) Azt hiszem, amúgy rövidebb kieséseket már maga a TCP is elfed.

    2) abban igazad lehet, hogy egy feltört szerver belemódosíthat a nyitott kapcsolatokba. Dehát ez bármelyik mai internetes protokollnál (http, ssh, mysql) előjön. Ezt nem érzem olyan borzasztó veszélyes dolognak, mivel a szerver csak azzal a részével áll kapcsolatban a kliensnek, amit az szándékosan a gondjaira bízott. (cons, form, vagyis egyetlen konzol- vagy form ablak) Abban meg nem követhet el olyan durva dolgokat.

    Ezeket a problémákat nem látom olyan nagyon kritikusnak.

    +) épp ez a lényeg, hogy a protokoll lényegében csak a felületi mozgást tartalmazná. kliens részről konzolnál csak a beírt vagy kiírt sorok mozognak. Formos felület esetén a form(ok) felépítése után csak a gombnyomások, kiválasztások, szövegbevitelek, és a form- változások mozognak.
    Épp ellenkezőleg, pont hogy pontosítható osztályokat képzelek el. Ha kiderül, hogy egy portálnál nagyon hiányzik a PageControl ami esetleg nincs a dev://form-ban, mint vezérlőelem, akkor a szerver dev://form helyett mondjuk ngp://ngp.org/form2.intf (New Great Protocol) interfészű objektumot vár, és ha a kliens tud ilyen objektumot biztosítani, akkor ugyanezzel a protokollal mehet minden ugyanúgy.

    A hardvergyorsítással ugyanez. Mivel csak a protokoll kötött, a kliens úgy valósítja meg az eszköz-objektumait, ahogy akarja. A konzolt magát megírhatja C-ben, gépi kódban, bárhogy, az az ő dolga. Használhatja a platformja saját widget készletét, bármit. Amíg az a dev://form osztály interfészét tartani tudja, a kapcsolat jól fog működni.
    Mutasd a teljes hozzászólást!
  • Az ötlet nem rossz, csak ez így nagy káoszt okozna. Mert:

    1) El tudod ezt a kommunikációt képzelni mondjuk mobil internet eléréssel? Miközben autóban ülsz, és éppen hegyek közt utazol, kb. 50km alatt 50-szer fog megszakadni a kapcsolat. A megoldásod azért borulna, mert nagyon sok apró kommunikáció szükséges a kliens és a szerver között az üzemszerű használathoz, amit az 50 reconnect (már csak iszonyú lassúságából adódóan is) simán tönkre tenné. Szóval ez a megoldás instabil, megbízhatatlan internet eléréssel használhatatlan lenne.

    2) Hatalmas káoszt okozna, ha egy feltört szerver kártevőt terjesztene a hálózaton. Mivel a megoldásod bármikor kezdeményezhetné a szerver részéről a kliensek felé indított kommunikációt, így egy rosszindulatú programot pillanatok alatt sok ezer kliensnek oda tudna "ajándékozni" a feltört és manipulált szerver. Ez meg nem hinném, hogy sokaknak tetszene, mivel így egy 4 magos gép esetén 3 magot oda lehetne adni a víruskeresőnek...

    Ha ezen fenti problémákra tudsz hatékony megoldást, illetve kő keményen kőbe vésett osztálykönyvtárral rendelkezne a rendszer (mindenkor 100%-ig garantált visszafelé kompatibilitással), akkor bizony még életképes is lehetne az ötleted, ha jó erős, hardveres gyorsítási képességeket is kihasználni tudó klienssel rendelkezne.

    Ugye, hogy nem is olyan egyszerű ez?
    Mutasd a teljes hozzászólást!
  • Az elképzelés valami olyasmi, hogy a kliens és a szerver
    valamiféle objektum-orientált nyelven beszélgetnek.
    A nyelv lehetőséget adna interfészek (saját osztályok)
    definiálására. A TCP kapcsolaton belül létrejövő objektumok
    műveleteit bármelyik oldal hívogathatná.

    Egyszerű példaként konzol kommunikáció:
    (a sor eleji <, > jelek, illetve a #-el kezdődő sorok
    nem részei a kommunkációnak)

    # a ? kérést, az = választ, az & speciális # parancsot jelent # kliens kezd, kéri a szerver interfészét >? # szervernek egy művelete van <=1 # neve consoleui és egy dev://console # osztályú paramétert vár a klienstől, # javasoltan cons névvel # a dev://console beépített osztály <consoleui dev://console <cons> # kliens meghívja a műveletet a saját # konzolával, amit cons-nak hív >?consoleui cons # a hívásnak nincs visszatérési értéke # a szerver megjegyzi a nevet <=0 # a szerver ír a konzolra <?cons.writeln 'What is your name?' # a kliens kiírja a szöveget a felhasználónak # és nyugtázza a kérést >=0 # a felhasználó beírja a nevét, és az továbbítódik # a szerver felé >?cons.readln 'Buck' # szerver nyugtázza a beírt sort <=0 # szerver kiírat egy új sort <?cons.writeln 'Hello, Buck' #kliens nyugtáz >=0 # szerver bontja a kapcsolatot <&disconnect

    Grafikus felületű példa, a Google nyitólapja:

    >? <=1 # a szerver most form felületet vár form névvel <formui dev://form <form> >?formui form <=0 # a szerver felépíti a formot, egyszerre 7 kérést # küld <?7 # az űrlap függőlegesen oszlik öt részre <form.splitVert 5 # első rész neve javasoltan <form.part 1 <header> # a második rész a logo <form.part 2.addImage http://www.google.hu/images/srpr/logo3w.png # beviteli mező, javasolt neve <input> <form.part 3.addInput <input> # keresőgombok és neveik <form.part 4.addButton 'Google keresés' <bsearch> <form.part 4.addButton 'Jó napom van' <blucky> # lábléc <form.part 5 <footer> #kliens nyugtáz, elfogadja a neveket, ahol nem volt javaslat, ott ő mond nevet >=6 >header >image1 >input >bsearch >blucky >footer #szerver befejezi a fejlécet és a láblécet <?15 <header.splitHorz 9 <header.part 1.addText 'Web' <header.part 2.addButton 'Képek' <bimages> <header.part 3.addButton 'Térkép' <bmaps> <header.part 4.addButton 'Hírek' <bnews> <header.part 5.addButton 'Fordító' <btranslate> <header.part 6.addButton 'Tudós' <bscholar> <header.part 7.addButton 'Gmail' <bgmail> <header.part 8.addButton 'Továbbiak' <bothers> <header.part 9.addButton 'Bejelentkezés' <blogin> <footer.splitHorz 4 <footer.addButton 'Hirdessen a Google-on!' <bads> <footer.addButton 'Rólunk' <babout> <footer.addButton 'Google.com in English' <benglish> <footer.addButton 'Adatvédelem' <bprivacy> #kliens nyugtáz >=12 >bimages >bmaps >bnews >btranslate >bscholar >bgmail >bothers >blogin >bads >babout >benglish >bprivacy #kliens beírja a keresőkifejezést >?input.setText 'Numa numa' #szerver nyugtáz <=0 #kliens keres >?bsearch.click #szerver nyugtáz <=0 # ... stb # (a szerver átalakítja a középső részt és kiírja az eredményeket) #klilens kilép >&disconnect

    Mit gondoltok? Érdekes? Hülyeség?
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Érdekes elmélet, azonban én nem látom, hogy miért függene egy egységes platform kialakítása a típusosságtól.

    Szigorúan technológiai szemmel nézve nincs akadálya az egységes, előfordított (típusos nyelvvel készült) tartalom megjelenítésének: ld. létező technológiák.

    A HTML5 is jeleníthetne meg előfordított, típusos köztes-kódot, nem?

    Én inkább üzleti érdekeket látok, amelyek egymással versenyeznek (aki ezt a piacot uralja, kaszál), ezért van több párhuzamos ilyen megoldás. A HTML5 meg a kompromisszum.
    Mutasd a teljes hozzászólást!
  • A 4 "nyelvhez" azért még hozzá tenném a (My)SQL-t és a RegExp-et, is. De a JSON és az XML ismerete se árt. A JQuery pedig az egyik leghasznosabb kiterjesztése a JS-nek.

    Amúgy ez a kérdés bennem is számtalan formában megfogalmazódott. Én alapvetően flash fejlesztő/designer oldalról érkeztem. A flash nagy előnye, hogy minden böngészőben egyformán fut. Jól használható animációs könyvtárral rendelkezik, amivel szinte tetszőleges interface-t ki lehet alakítani. Ezért a flash programozók így is tesznek (a felhsználók pedig találgatnak, hogy mit hogyan). Ugyanarra a problémakörre ezer megoldás van. Így sokkal nehezebb még a forrás megléte mellett is átlátni és módosítani egy más által megírt kódot.
    A fő hibája azonban az, hogy egy flash program egy zárt egységet képez, amibe nincs igazán belátásuk a böngészőknek, vagy a keresőknek. Így nem tudnak olyan kiegészítéseket alkalmazni rá, mint például a helyesírás elemzés.
    A legnagyobb hibája azonban a flash-nek a szövegkezelés. Amire az új textFlow engin-el próbáltak javítani, de kicsit mellé lőttek, szerintem, amikor egy ilyen alapvető funkciót ennyire elbonyolítottak.
    A HTML legnagyobb előnye a CSS leíró nyelv, aminek vannak ugyan nehezen emészthető részei, mégis messze jobban lehet vele strukturálni egy weboldalt, mint flashben.

    Mindkét út jól járható és mindkettő ezer sebből vérzik. A kérdés az, hogy mi lenne a bölcsek köve? Egy olyan nyelv ami mindenre jó? Vagy bízzuk magunkat a cyber evolució 9 fejű gyermekére mint a legéletképesebb megoldásra.
    Én speciel várom a programnyelvek fejlődését. Addig meg használom ami van.
    Mutasd a teljes hozzászólást!
  • Az appletek, mint minden más közvetes vagy végleges kódra fordított technológia azért nem terjedt el igazán sosem a weben, mert alapvetően szembemegy a web alapjaival. Gyakorlatilag minden előre fordított program erősen zárt és monolitikus valahol (akkor is ha kifelé amúgy jól definiált interfészeken át kommunikál, ami mellesleg azért elég ritkán jellemző alkalmazásszinten), ami tökéletesen ellentétes a web dinamikus, moduláris és kollaboratív természetével. Az egész web lényege az, hogy sok ember csinál önmagában valami viszonylag kicsit, és ezt kapcsoljuk össze egy nagy, szerves, együttműködő valamivé.

    Ezt azonban hatékonyan fordított technológiákkal nem, csak dinamikus nyelvekkel lehet megoldani. Ill. egészen pontosan nyilván fordított nyelvekkel is meg lehet oldani, de csak dinamikus típuskezeléssel, dinamikus erőforrásbetöltéssel, stb., amely esetben elveszik a fordítottság minden előnye a dinamikus nyelvekkel szemben, és ami marad, az csak a hátrányok: a merevség, az esetleges platformfüggés, az utólagos módosítás lehetetlensége futásidőben ill. a forrás hiányában, stb.

    A másik dolog, hogy a web annak ellenére, hogy ez már legalább egy évtizede buzzword, még mindig nem szemantikus - legalábbis általánosságban nem -, hanem erősen szöveges alapú. Ez igaz mind a benne tárolt információkra, mind azokra a infrastruktúrális nyelvekre, protokollokra, amik segítségével működik. Mivel azonban sztring alapú, azaz mind a bemenetet, mind a kimenetet sztringek képezik, ezért pl. az, hogy integerekkel vagy erősen struktúrált elemekkel és szerkezetekkel egy szigorúan típusok, natív, (elő)fordított kód gyorsabban dolgozik, mint egy dinamikus, értelmezett, teljesen irrelevánssá válik - mert a ténylegesen és intenzíven használt része, a sztringkezelése úgysem lehet alapvetően gyorsabb, ráadásul utóbbi feldolgozási erőforrásigénye mellett eltörpülnek a feldolgozó alkalmazásokód futtatását esetleg némileg lassító faktorok (mint pl. a kód értelmezésének szükségessége). Ez megint csak azt jelenti, hogy a fordított kód előnyei weben nem tudnak kijönni, csak a hátrányaik, ami impraktikussá teszi alkalmazásukat.

    Ráadásul ez utóbbi (ti. a feldolgozó alkalmazáskód futási sebessége) olyan faktor, ami tíz évvel ezelőtt még azért lehetett tétel - nem is véletlen, hogy akkoriban még viszonylag erős volt a Java és az ActiveX is a weben; mára azonban jelentéktelenné vált. Azért, mert mára elég erősek a processzoraink és elég optimalizáltak a böngészőmotorjaink ahhoz, hogy gyakorlatilag az igen speciális, kifejezetten erős számításigénnyel rendelkező alkalmazásokat leszámítva minden feladatot elfogadható sebességgel hajtsanak végre. Azaz, a gyakorlatban kezd elveszi a natív, erősen típusos kód azon előnye is az értelmezett, dinamikus nyelvekkel szemben, hogy némileg gyorsabb a végrehajtása.

    Na, többek között ezekért nem váltotta - és nem is úgy néz ki, hogy belátható időn belül fogja - akármilyen fordított platform leváltani a mostani webes technológiákat, sőt, ami inkább valószínű az, hogy utóbbiakat (beleértve a Java, az ActiveX és a hasonlók mellett a .NET-et is) inkább a dinamikus nyelvek fogják leváltani rendkívül sok téren. Még a weben kívül is.
    Mutasd a teljes hozzászólást!
  • Még a java áll a legközelebb ahhoz, amit elképzelek.

    A Java appletek már vagy 10 éve nagyrészt halottak. Volt egy comeback kísérlet JavaFX néven, de nem igazán akar elterjedni. Hogy pontosan mi volt az Applet halálának oka, arról megoszlanak a vélemények. Lehetséges okok pl.:

    - iszonyú nagy load time az appletek esetén
    - A JAva-s UI technológiák nehézkessége. Ebben a Java soha nem volt erős, 2011-ben elértünk oda, hogy a Swing már egész szép az új default look and feel-el (Nimbus), de miért kellett ehhez több mint 10 év? A mai napig nincs fejlett stilizálási rendszer a Swingben (meg sem közelíti a CSS kifinomultságát, de pl. a QT stylingja is fejlettebb). Pedig a Java GUI radásul toldozott foldozott: kezdetben volt a borzalmas AWT, ami a natív kontrollokra épít, ezekre építették következő rétegként a Swinget, amiben már vegyesen vannak szoftveresen rajzolt widgetek is a natívak mellett... Sok jó ötlet van a Swing-ben, de azért a befektetett energiához mérten többet is lehetne tőle várni.
    Mutasd a teljes hozzászólást!
  • HTML5ből amennyit ismerek, csakugyan derék vállalkozás, csak hát ott ül az (idézem) kártyavár tetején. Ahhoz, hogy html5-ös oldal megjelenjen, egy megfelelő böngésző kell, ami manapság azt jelenti, hogy mondjuk a legnépszerűbb 5-ből kell kiválasztani egyet.



    És abból is néha a megfelelőt :) Pl a topikban látható url csak chromeban működik (ie9-ben, ff-ben nem...)

    http://mediamaxdesign.bplaced.net/
    Mutasd a teljes hozzászólást!
  • Ilyesmire vártam, köszönöm.

    Bennem változatlanul az van, hogy igen sok múlik a protokollon/nyelven. Szerintem a HTML azért tudott terjedni, mert az alap HTML nyelv nem túl bonyolult, az alap HTTP protokollról nem is beszélve. És onnantól mindenkire rá volt bízva, hogy milyen böngészőt, illetve milyen webszervert ír. A kezdetben aránylag kis nyelvet aránylag könnyű volt feldolgozni, a böngészők pikk-pakk megjelenítették, ami le volt írva. Csak nekem az van a fejemben, hogy az igények túlhaladtak az eszközön, és ma már sem a nyelvek, sem a böngészők nem átláthatók, mert mindenki azt csapta hozzá, ami neki épp kellett, anélkül, hogy átgondolták volna, mi változott az elvárások terén, és mit kellene gyökeresen másképp.

    Minden tiszteletem azoké, akik ma kiigazodnak a számos HTML/CSS/Javascript szabvány között, és tudnak olyan weboldalakat építeni, amik szépen futnak szöveges böngészőtől kezdve mobilon keresztül nyolcmagos grafikusan gyorsított erőgépekig mindenen, de az a gyanúm, hogy most ehhez aránytalanul sok energiát kell bevinni a fejlesztő részéről.

    Flashről írtam az előbb, Silverlighttal lényegében ugyanígy vagyok, ActiveX tudtommal erősen windows rendszerhez kötött.

    Még a java áll a legközelebb ahhoz, amit elképzelek. A nyelv igen erős, bár ma már egy kicsit talán túl az. Nem nagyon ül le senki java fordítót írni csak azért, hogy a saját kis rendszerére belője a dolgot. Minden könyvtárával együtt talán már a futtatókörnyezet is túl terebélyes ahhoz, hogy egy böngészőprogramba illeszthető legyen, és számtalan olyan szolgáltatást nyújt, ami egy webportálnál teljesen felesleges. Ugyanakkor pl. a webportáloknál gyakori session kezelés az appletekből hiányzik, a megjelenítés ha jól emlékszem képpont alapú, és már most legalább 4-5 élő java változat van, nem beszélve arról, hogy igen sok környezet nem teljesen kompatibilis egymással.

    Nem kötekedésből, de a javában sem érzem 100%-ig azt, hogy épp erre volna szükségem, ha aránylag gyorsan egy aránylag jó webportált össze akarok rakni.

    HTML5ből amennyit ismerek, csakugyan derék vállalkozás, csak hát ott ül az (idézem) kártyavár tetején. Ahhoz, hogy html5-ös oldal megjelenjen, egy megfelelő böngésző kell, ami manapság azt jelenti, hogy mondjuk a legnépszerűbb 5-ből kell kiválasztani egyet.

    Amiből az következik, hogy mondjuk az egy két éven belül megjelenő mondjuk TV-be épített böngészők nemigen fogják támogatni, hisz ahhoz az egész WWW-szabvány-kavalkádat tudniuk kellene.



    Mutasd a teljes hozzászólást!
  • A fejlesztők bizalmának elnyeréséhez előnyös, ha legalább olvasásra nyitott a forrás.
    Utánanéztem, hogy hogyan lehet pénzt csinálni OpenSource cuccból.

    Arra jutottam, hogy az egyik klasszikus megoldás, hogy a cég 'supportból', 'könyvekből', tanácsadásból és egyéb bullshitelésekből próbál pénzt csinálni.
    Ezeknek van néhány hátránya számomra. Az egyik, hogy bullshitelésben nem vagyok (annyira) jó; könnyen lenyom a konkurrencia. Másrészt ez arra ösztönzi az embert, hogy minél inkább agyonbonyolítottabb cuccot csináljon, hogy legyen miről 1000 oldalas könyvet írni, legyen mit supportálni. Harmadrészt senki nem akadályozza meg a konkurrenciát, hogy supportálja az általam fejlesztett technológiát, vagy könyvet írjon róla, miközben nekem kell erőforrásokat beletenni a fejlesztésbe. Én ezt a verziót kilőttem.

    A másik verzió, hogy ugyan bárki olvashatja a forrásodat, de mégis pénzes licensszel tudják/(fogják akarni) használni azok az üzleti felhasználók akik meg is tudják fizetni.

    Erre a célra jelenleg a következő licensz tűnik a legjobbnak (találtam pár céget aki ezt használja, most úgy gondolom, hogy én is ezt fogom használni):

    Dual AGPL + fizetős licensz.

    Ez kb. azt jelenti, hogy bárki, aki közreadja a teljes webappjának a forrását, ingyen használhatja a cuccot, de aki nem akarja közreadni (a legtöbb üzleti felhasználó), az fizet a licenszért.

    Még mielőtt valaki azt mondaná, hogy a JS mindenképpen opensource: productionban minified gzipped JS megy ki a böngészőbe, a forrás közreadása azt jelenti, hogy az ember a (fejlesztők részére) letölthetővé teszi az eredeti kommentezett nem minified forrást.
    Mutasd a teljes hozzászólást!
  • Milyen sokfélék az emberek. Én részemről a zárt forrást húztam ki először, tekintve, hogy az oda vezet, hogy egy lokális fejlesztőcsapat próbálja a saját elgondoldolásait több nagyságrenddel több emberre ráerőltetni.


    Ez igaz, viszont egy cég/csapat kell az irányításhoz (minimum a tesztelési fázisban), különben szétfolynak a megvalósítások (lásd böngészők).
    Itt kezdődtek a problémák, pl ms megcsinálta a színátmenet lehetőségét ie6 alatt már, most (jóval később) bevezették a css3-ban(?). Így ie-ben a régi megoldást kell használni, más böngészőkben meg az újat (azt is máshogy böngészőnként).
    Mutasd a teljes hozzászólást!
  • Milyen sokfélék az emberek. Én részemről a zárt forrást húztam ki először, tekintve, hogy az oda vezet, hogy egy lokális fejlesztőcsapat próbálja a saját elgondoldolásait több nagyságrenddel több emberre ráerőltetni. Tudom, hogy volt már ilyen, de a magam részéről ehhez nincs elég kapacitásom.

    Flexet nem ismerem.

    Flash-sel szerintem épp az van, amit én írok. Egy-két architektúrára létezik, nincs energiájuk többre. És ha jól tudom gyakorlatilag csak x86-on fut hatékonyan. Már én olyanokat is hallottam, hogy az alma azért nem támogatja valami eszközön, mert bizonyos biztonsági réseket nem tömnek, hibákat nem javítanak ki.

    Zárt forrásnál óhatatlanul előjön, hogy mi a fejlesztő cég érdeke, és milyen lépéseket engedhet meg magának.



    Mutasd a teljes hozzászólást!
  • Amit írsz az csak megerősíti bennem, hogy volna szükség ilyesmire. Nem tudom, mit értesz azalatt, hogy vastag kliens, ha ugyanazt mint én, hogy a desktop gépre programot tenni, az egy nagyon fontos dolgban hátrányban van a böngészőhöz képest, abban, hogy telepíteni kell, és a hatékony működéshez a konkrét architektúrára kell fordítani. Ez már két platfromnál sem kevé munka. Nem beszélve arról, hogy a telepítés nem kis bizalmat feltételez a program írója irányában, ami például egy webshop esetén nem kellene elvárás legyen.

    Úgyhogy még nem adtam fel, az összefoglalás szellemes.
    Mutasd a teljes hozzászólást!
  • Arra lennék kíváncsi, hogy mennyien értenek egyet azzal a véleménnyel, miszerint a webes alkalmazások jelenleg olyan eszközzel és protokollal épülnek, amit egész másra találtak ki annak idején.


    Ezzel szvsz mindenki egyet ért, bár a HTML5 azért enyhít a dolgon valamennyit.

    A fő kérdés arra vonatkozik, hogy van-e valakinek ötlete/energiája arra, hogy új valamiféle portál-leíró nyelvet találjon ki? Vannak esetleg ilyenek? Ha vannak, akkor mi az oka, hogy nem látszanak jelek arra, hogy a HTML/CSS/JS jelentősége csökkenne?


    Ez nem szimplán protokoll, hiszen a protokollok a hálózati kommunikáció részért felelnek csak. Amit te szeretnél az egy új webes alkalmazásfejlesztési technológia. De az általad felsoroltaknak megfelelő technológiák már léteznek: flash, java, silverlight/moonlight, activex, stb.. Mindegyiknek vannak előnyei és hátrányai, de ettől még léteznek és használják is őket.
    Mutasd a teljes hozzászólást!
  • Ezt én sem gondolom másként.
    Mutasd a teljes hozzászólást!
  • Én is tudnék jobbat elképzelni, de ez is klasszisokkal jobb a böngészőkkel való szívásnál.
    Mutasd a teljes hozzászólást!
  • A flex jó koncepció de elég körülményes benne a kódolás.
    Mutasd a teljes hozzászólást!
  • Már egy elterjedt, zárt forráskódú böngésző alternatíva, saját nyelvvel/nyelvekkel is nagy előrelépés lenne.
    Én ma a flash playert/airt (csak az utóbbi nem annyira elterjedt) + flex-et, mint fejlesztési technológia találom a legjobb alternatívának.
    Mutasd a teljes hozzászólást!
  • A vastag kliens tudja mindazt amit te szeretnél. A böngészőben futó keretrendszerek (extjs , gwt ..) pedig azáltal, hogy egyre inkább szeretné magát vastagkliensnek láttatni valóban agyrémmé vált a kismillió rétegével.
    Hogy néz ki a web fejlesztés napjainkban?

    - A böngésző biztosítja a biztonsági réseket és a memória szivárgást.
    - A html értelmező a megjelenítés kompatibilitás problémáit.
    - A javascript a működésbeli kompatibilitás problémáit.
    - A json megfejeli a gondot a visszafelé kompatibilitási hibákkal.
    - Az extJS megfejeli a json hibáit a maga kis kompatibilitási gondjaival.
    - Majd ha mindezek ellenére elkészül egy oldal lehet imádkozni hogy a következő böngésző verziókban ne végezzenek olyan módosításokat ami mindezekre kihatással lehet.

    Az egész koncepció egy kártyavárra hasonlít leginkább.
    Mutasd a teljes hozzászólást!
  • Most ez az új divat? Az új operációs rendszer írása már "so 2000 and late", úgy hogy most az új protokoll írása a titánok nagy kihívása?
    Mutasd a teljes hozzászólást!
  • Sziasztok,

    Arra lennék kíváncsi, hogy mennyien értenek egyet azzal a véleménnyel, miszerint a webes alkalmazások jelenleg olyan eszközzel és protokollal épülnek, amit egész másra találtak ki annak idején.

    Az mennyire igaz, hogy ma ahhoz, hogy valaki tisztességes webes programot írjon, azt kb. 4 nyelven HTML, CSS, JS, PHP kell megtegye?

    Igaz az, hogy ebből a HTML eredetileg dokumentum leíró-, a PHP script-, a CSS/JS pedig utángyárott hiány-foltozó nyelv? Hogy a HTTP alapvetően állapot-nélküli dokumentum lekérő nyelv? Hogy ezt a fából vaskarika rendszert űzik hosszú évek óta rengetegen, és ez néha bosszúságokat okoz?

    A fő kérdés arra vonatkozik, hogy van-e valakinek ötlete/energiája arra, hogy új valamiféle portál-leíró nyelvet találjon ki? Vannak esetleg ilyenek? Ha vannak, akkor mi az oka, hogy nem látszanak jelek arra, hogy a HTML/CSS/JS jelentősége csökkenne?

    Ilyesmiket szeretnék, ha megosztanátok, hogy
    "ha volna ilyen protokoll, akkor annak ..."

    - TCP kapcsolat fölött kellene működnie
    - meg kellene adnia a lehetőséget arra, hogy a
    szerver is kezdeményezhessen változást a
    böngészőablakban
    - tudnia kellene böngésző pluginnel, vagy
    külön natív klienssel (pl. mobilon) működni?
    - jó volna, ha alapelemekből épülne fel, amikből
    összetettebb vezérlőelemeket lehet kialakítani
    - lehetőséget kellene adnia, hogy ugyanazt a
    szolgáltatást különféle szinteken (desktop,
    mobil, webservice) lehessen elérni

    ...?
    Mutasd a teljes hozzászólást!
abcd