[alg] Rich clients. Waarom geen X gebruiken?

[Verwijderd]

Een lange tijd zijn web applicaties redelijk simpel van opzet geweest. De rijkheid die met traditionele toolkits mogelijk was miste je behoorlijk. De laatste tijd is hier wel een verschuiving te zien naar server modellen die meer de traditionele client-side approach nadoen, met MVC structuren, events, echte re-usable components etc.

Echter, er bestaat al heel erg lang een techniek die al deze facetten reeds heeft, namelijk het X window systeem. Je kunt dit als back-end gebruiken voor vele andere toolkits (met name Motif, GTK, en Qt) die alles (en meer!) beheersen wat nu langzaam in de zogenaamde web-frameworks zit te komen.

Natuurlijk was X nooit super-optimized voor Internet gebruik, maar meer op lokaal netwerk gebruik gericht. Via een modem verbinding was er amper mee te werken, maar via breedband wel goed (alhoewel hier nog wel wat werk verzet kan worden).

De toegankelijkheid hoeft ook amper een probleem te zijn. Bijna alle desktop operating systems komen al met een X server, en voor die ene die dit niet standaard heeft voldoet een enkele download.

Er zouden verder nog wel wat uitbreidingen noodzakelijk zijn, zoals het makkelijk kunnen opstarten van een remote application ( een URL intikken is makkelijker dan inloggen en een commando intikken), maar de complexiteit van deze noodzakelijke uitbreidingen lijken me veel minder dan compleet nieuwe frameworks op te zetten.

Waarom ligt dan toch de toekomst in de web frameworks zoals ASP.NET en JSF, en niet in het reeds bestaande X?

[NMe]

Verwijderd schreef op woensdag 26 oktober 2005 @ 20:50:
Waarom ligt dan toch de toekomst in de web frameworks zoals ASP.NET en JSF, en niet in het reeds bestaande X?

Omdat X gewoon niet bedoeld is als framework voor een webapplicatie?

Sowieso ligt ASP.NET er al, terwijl jouw idee talloze aanpassingen nodig heeft om überhaupt van de grond te kunnen komen. Nogal logisch dat de toekomst dan vooralsnog in elk geval niet bij X ligt voor dit soort zaken.

[Verwijderd]

Verwijderd schreef op woensdag 26 oktober 2005 @ 20:50:
Waarom ligt dan toch de toekomst in de web frameworks zoals ASP.NET en JSF, en niet in het reeds bestaande X?

Ik denk marketing redenen, en omdat niet iedereen 100Mb internet heeft.

Ik ben het wel helemaal met je eens.

[mocean]

Er is al wel al een andere implementatie van het systeem dat je beschrijft, namelijk via een Citrix server (ik weet verder weinig over de implementatie).

Zie als voorbeeld: http://www.delftgeosystems.nl/nl/page6807.asp

Je moet eerst een Citrix Web Client installeren, en dan kan je op/vanaf de server de applicatie draaien. Op bovengenoemde site wordt het gebruikt voor een demo van het programma.

[Verwijderd]

Ik denk dat het een paar redenen heeft:
1) install base en bekendheid met web browsers: heel veel gebruikers hebben geen flauw benul van computertechnologie, dus veel verschillende termen en concepten verwart hen. Webbrowsers zijn bekend, iedereen heeft ze, ze werken behoorlijk uniform, mensen kunnen er nu mee overweg en vertrouwen ze. Daarom is het bouwen van een nieuwe laag op die bestaande technologie voor de applicatieleveranciers (zoals Google) erg aantrekkelijk.

2) bestaande infrastructuur: veel netwerken zijn ingericht op het gebied van security om http via poort 80 toe te laten. Om dit op een massale schaal (binnen bedrijven, internetproviders, etc) aan te passen is een enorm karwei. Denk ook aan devices en software die gericht zijn op http verkeer, zoals proxy en caching servers.

3) investering in huidige applicaties vs nieuwe technologie: bedrijven stappen bij het opkomen van nieuwe technologie alleen direct over als ze er acute behoefte aan hebben. In andere gevallen wachten ze tot de nieuwe technologie tot die zich uitvoerig bewezen heeft en er een duidelijke reden is om over te stappen. Ze zijn eerder geneigd om het oude te willen behouden en uitbreiden, omdat die investeringen sneller iets oplevert in hun beleving.

4) staat van de technologie: Natuurlijk bestaat X al heel lang, en zijn toolsets als Mtoif en Qt ook de jongste niet meer, maar ze zijn mijns inziens nog nooit toegepast voor de toepassingen waar nu van een webbrowser gebruik wordt gemaakt. Zou een BOL.com of amazon kunnen draaien op een X achtige omgeving morgen of overmorgen, met het aantal ingelogde gebruikers zoals nu, met alle audit fasciliteiten, koppelingen naar partners, etc? Nee. Het kan wel, maar voor dit soort toepassingen is er gewoon te weinig ervaring.

5) Connected vs disconnected: Heel lang was een sterk punt van de webapplicatie dat er alleen maar een connectie was ten tijde van het opvragen en overhalen van een webpagina. Daardoor was de netwerkbelasting ook lager dan met connected systemen, waardoor rustig 10.000 bezoekers tegelijkertijd op een webapplicatie kunnen komen, omdat maar een tiende op dat moment een connectie heeft.
Met opkomst van technieken als AJAX komt dit natuurlijk wel op de schop te staan, maar het is niet voor niets dat die techniek nu opkomt: de netwerken kunnen nu beter enorme hoeveelheden connecties aan.

Ik zie browsers voorlopig niet van het toneel verdwijnen. Wel denk ik dat de connectiviteit steeds meer zal verschuiver naar AJAX achtige interactie, waarbij niet hele pagina's maar alleen benodigde gegevens op basis van een event zullen worden overgehaald. Wellicht dat een nieuwe HTML versie (iets meer XML compatible) en DOM (meer events e.d.) binnen de browser al zoveel kan bereiken, dat klassieke client side applicaties grotendeels a thing of the past worden.

[chris]

Het is leuk dat je met je webbrowser heel veel applicaties kunt gebruiken. Ik denk ook dat de komende jaren alleen meer meer RIA's zullen ontstaan. Waarschijnlijk zal het daarna weer afnemen, omdat mensen er weer achter komen hoe fijn het is als ze zelf hun dingen kunnen beheren en niet afhankelijk zijn van derden. Er is altijd al een grote schommeling geweest tussen thin clients en fat clients, nu schuift het door dingen als gmail enzo weer steeds meer richting thin clients, ik gok dat dit over een aantal jaar dus weer teruggaat.

Verder sluit ik me helemaal aan bij MrX

[Verwijderd]

Verwijderd schreef op woensdag 26 oktober 2005 @ 22:16:
Ik denk dat het een paar redenen heeft:
1) install base en bekendheid met web browsers: heel veel gebruikers hebben geen flauw benul van computertechnologie, dus veel verschillende termen en concepten verwart hen. Webbrowsers zijn bekend, iedereen heeft ze, ze werken behoorlijk uniform

De modernere web applicaties, die veel meer "applicatie" zijn een veel minder "web" of "web site' hebben dat veel minder. Die gaan zowel kwa look als kwa feel steeds meer naar desktop applicaties toen. Gevolg is dan dat dingen zoals een back-button of een link (bookmark) totaal geen nut meer hebben. Je zit dit nu al met heel veel web toepassingen en dan met name diegene die Ajax achtige technieken gebruiken.

Het geheel speelt zich wel in een browser af, maar je browsed helemaal niet meer in de applicatie maar werkt er mee. Het nut van de browser vervalt dan een beetje. Alleen het launch mechanisme (=intikken van URL) blijft dan bestaan.

Je zou je echter ook kunnen indenken dat je via een Java webstart achtige methode net zo goed een X sessie via het web kan starten. Desnoods embed je de X client area los van je main X direct in de browser. Zoals gezegd bijna elk OS heeft standaard al een X server. Voor Windows is het een aparte download, maar ach, mensen downloaden ook flash wat daarom niet X?

4) staat van de technologie: Natuurlijk bestaat X al heel lang, en zijn toolsets als Mtoif en Qt ook de jongste niet meer, maar ze zijn mijns inziens nog nooit toegepast voor de toepassingen waar nu van een webbrowser gebruik wordt gemaakt. Zou een BOL.com of amazon kunnen draaien op een X achtige omgeving morgen of overmorgen, met het aantal ingelogde gebruikers zoals nu

Goed punt, en eigenlijk zeg je met 5) ook een beetje hetzelfde. Traditioneel was X ook bedoeld voor 1 server met veel clients, maar die draaide dan wel allemaal aparte applicaties.

Bij web applicaties gaat het meestal inderdaad om 1 applicatie waar meerdere users op inloggen. Elke user request is dan een thread en elke user is hooguit wat data in een sessie. Bij X zou elke user toch tenminste een process zijn. Feitelijk start je het hele grafische programma telkens opnieuw op voor elke client. Hier valt vast wel het een en het ander aan te tweaken, maar toch.

In de praktijk heb ik vroeger op de Universiteit op een systeem gewerkt waar als server een quad ultra sparc stond die een stuk of 30 clients had met domme X-terminals. Hier deed je dan wel zwaardere dingen mee als wat de gemiddelde web applicatie doet.

[Mithrandir]

Verwijderd schreef op woensdag 26 oktober 2005 @ 22:44:
[...]


De modernere web applicaties, die veel meer "applicatie" zijn een veel minder "web" of "web site' hebben dat veel minder. Die gaan zowel kwa look als kwa feel steeds meer naar desktop applicaties toen. Gevolg is dan dat dingen zoals een back-button of een link (bookmark) totaal geen nut meer hebben. Je zit dit nu al met heel veel web toepassingen en dan met name diegene die Ajax achtige technieken gebruiken.

Het geheel speelt zich wel in een browser af, maar je browsed helemaal niet meer in de applicatie maar werkt er mee. Het nut van de browser vervalt dan een beetje. Alleen het launch mechanisme (=intikken van URL) blijft dan bestaan.

[..]

In de praktijk heb ik vroeger op de Universiteit op een systeem gewerkt waar als server een quad ultra sparc stond die een stuk of 30 clients had met domme X-terminals. Hier deed je dan wel zwaardere dingen mee als wat de gemiddelde web applicatie doet.

Ten eerste is het bookmarkprobleem als je ajax gebruikt een implementatiepunt. In mijn ogen zou de (ajax)webapplicatie bookmarken moeten blijven ondersteunen. Als een gebruiker dan bijvoorbeeld in het gebruikers-zoek-venster een bookmark maakt en later daar weer heen gaat, eerst een loginscherm krijgt dat weer doorverwijst naar het gebruikerszoekvenster.
Ook is een implementatie waarbij javascript non-obtrusive aanwezig is misschien ook handig: wanneer er geen javascript is gewoon met postbacks en verzendknoppen werken, als er wél javascript is de postback uitzetten en afhandeling via Ajax doen. Wanneer je echter een compleet nieuwe view aan de gebruiker laat zien, open je gewoon een nieuwe pagina. Met bijbehorende URL, zodat mensen nog steeds kunnen bookmarken.

Daarnaast is 30 clients op 1 server natuurlijk helemaal niets vergeleken met bijvoorbeeld 5000 clients op 1 server zoals op tweakers.net. (Nouja, tenzij ze rendertaken aan het uitvoeren waren, maar dat lijkt me sterk?)

Waar het op neer komt is dat een techniek als bijvoorbeeld Ajax prima gebruikt kan worden zonder de structuur en gebruiksmethode van het web te verstoren.

[Verwijderd]

Mithrandir schreef op woensdag 26 oktober 2005 @ 23:11:
[...]

Waar het op neer komt is dat een techniek als bijvoorbeeld Ajax prima gebruikt kan worden zonder de structuur en gebruiksmethode van het web te verstoren.

Waar het mij natuurlijk voornamelijk gaat is om de gebruiksmethode van het programmeren niet te verstoren (dit is /14 natuurlijk ). Bijna alle programmeurs zijn toch altijd het event-model gewend bij GUI's programmeren, en dit is met het web een beetje verloren gegaan.

Hoevaak lees of hoor je niet over programmeurs die genoeg hebben van het geneuzel om met requests en page parameters te werken etc terwijl ze gewoon een applicatie moeten maken. De manier van programmeren zoals je bijvoorbeeld met Swing, MFC, Motif, GTK, Qt, etc etc etc doet voelt vaak toch natuurlijker aan.

Er zijn natuurlijk ook wel weer (jongere) programmeurs die opgroeide met de web style van programmeren en nooit een echte client-side application hebben geschreven of onderhouden. Die zullen mischien dit model weer verdedigen (men komt altijd op voor hetgeen met kent, niet voor hetgeen wat opzich het beste zou zijn).

Echter, alle bestaande serieuze web platforms gaan toch steeds meer naar het client-side model toe, wat aangeeft dat dit toch wel voordelen had. Het X platform combineerd in principe de 2 voordelen van traditioneel client-side programmeren met het remote karakter van web apps.

Daarnaast is 30 clients op 1 server natuurlijk helemaal niets vergeleken met bijvoorbeeld 5000 clients op 1 server zoals op tweakers.net. (Nouja, tenzij ze rendertaken aan het uitvoeren waren, maar dat lijkt me sterk?)

Ik proef hierbij nog steeds het feit dat niet iedereen de term web applicatie helemaal onderscheid van web site. Hoewel de grens af en toe dun is, dat geef ik toe, is tweakers toch veel meer een web site.

Waar men echter voor het web heen wil is echte applicaties, alleen dan met een remote interface. Echte applicaties zijn gewoon alles wat je op je lokale computer nu al draait. Office, PDF reader, photoshop, the gimp, Eclipse, Visual Studio, Firefox, Thunderbird, noem het maar op.

Rendertaken uitvoeren zal dus ongetwijfeld wel gedaan zijn op het X systeem, maar ook gewoon compileren, spellings check op het document wat je aan het editten bent en andere dagelijkse taken.

Ik vraag me af of als je dergelijke taken via een web server laat lopen je dan nog 5000 users aan kunt? Zoals gezegd, men wil dus heel graag al tijden echte applicaties voor het web aanbieden. Via X werd dat al heel lang gedaan, het werkte uitstekend en er was geen voor programmeurs lastig framework voor nodig. Je gaat X zeker niet gebruiken voor web sites, waar 1 server 5000 users moet aankunnen. Uberhaupt ga je X niet gebruiken voor web sites, ik heb het hier echt over -echte- applicaties.

[ Voor 33% gewijzigd door Verwijderd op 26-10-2005 23:46 ]

[elevator]

X is - vanwege de bestaande, populaire implementaties - niet geschikt om over het internet te draaien (vreet veel te bandwidth, is erg latency gevoelig en heeft een vrij zware client app nodig)

Citrix's ICA protocol is al weer een stuk lichter en bied opzich technisch de mogelijkheden (en Citrix heeft behoorlijk wat licenties uit staan en het wordt dus ook veel gebruikt)

Een volwaardige applicatie heeft echter ook wat nadelen, om een normale applicatie te draaien heb je behoorlijk wat meer serverpower nodig dan dat je een groot gedeelte aan de client overlaat (zeker met een taal als PHP waar een request maar een zeer korte levensduur heeft).

Daarnaast zit je altijd met latency: een applicatie die in de US draait waarbij de verbinding voor ons een latency heeft van 120msec heeft voelt "laggy" aan voor Nederlanders en dat is slecht voor je beleving bij de gebruikers

[Mithrandir]

Verwijderd schreef op woensdag 26 oktober 2005 @ 23:36:
[...]

Tsja... Het probleem is altijd het verschil te blijven (willen?) zien tussen webapps en gewone apps. Als je het over 'zware' programma's hebt, is het inderdaad niet erg slim om voor het web te gaan ontwikkelen. Dat heeft ook weinig voordelen.

Je moet natuurlijk blijven kijken waar de kracht van de verschillende platformen liggen:

Je gaat geen webapplicatie schrijven voor intensieve grafische dingen. Wél voor snel inzicht in (specifieke) data. Voor data die over veel plaatsen verdeeld moet worden. Voor data die overal inzichtelijk moet zijn.

Je gaat geen gewone applicatie schrijven om op een forum een post te kunnen doen. Wél voor rekenintensieve dingen of dingen waar een snelle responsetijd essentieel is (bijvoorbeeld computerspelletjes).

Voor mijn gevoel schets je een probleem wat er eigenlijk helemaal niet is; het web wordt niet 'misbruikt' voor te 'zware' applicaties.


_{Overigens is het tegenwoordig met bijvoorbeeld Ruby on Rails wel mogelijk om met een soort event-based applicatie te werken waarbij het framework voor een state zorgt (vs. stateless frameworks waarin iedere pagina alle informatie weer 'weg' is).}

[ Voor 3% gewijzigd door Mithrandir op 27-10-2005 00:05 ]

[Verwijderd]

elevator schreef op woensdag 26 oktober 2005 @ 23:43:
X is - vanwege de bestaande, populaire implementaties - niet geschikt om over het internet te draaien (vreet veel te bandwidth,

De populaire implementaties vreten inderdaad te veel bandwidth ja. Daarom was het vroeger met een modem ook absoluut niet bruikbaar terwijl het web toen wel werkte. Vergeet niet dat het web toen de tijd eigenlijk gezien werd als de small-band tijdelijke oplossing voor "de zielige modem gebruikertjes". Microsoft wilde bijvoorbeeld de small-band helemaal overslaan en zich meteen richten op een toekomst waar iedereen broad-band had (ongeveer deze tijd dus).

Omdat de small-band tijd eigenlijk over is, zou je je kunnen afvragen of het web model voor applicaties (niet voor sites), mischien niet een beetje ingehaald is door de techniek.

Een X model (hoeft niet perse X zelf te zijn) kan nu in de praktijk werken, terwijl dat 10 jaar geleden voor de massa niet kon.

is erg latency gevoelig )

Latency gevoeligheid is wel een punt, dat zou beter opgelost moeten worden. Maar aangezien X nu in het overgrote deel lokaal gebruik wordt is er weinig development meer in die richting. Wellicht dat bij meer gebruik via het internet dat probleem sneller opgelost zou kunnen worden (kip & ei verhaal).

en heeft een vrij zware client app nodig

Dat valt toch harstikke mee? De "client-app" is alleen hetgeen wat de rendering commands van de server afhandeld en de events (mouse move enz) bij houdt en verstuurd. Dit verschilt in essentie weinig van een browser. Het verschil is dat een X server (ja ja, de naam is verwarrend) standaard veel rijker is dan een browser, en een hele grote grafische library heeft met oa widgets. Het enige dat client-side processing power kost zijn de (interne) bewerkingen die de widgets zelf doen. Dit is in groten lijnen vergelijkbaar met bewerkingen die AJAX widgets zouden doen lokaal.

Ik snap dus niet helemaal waar jij het vrij zware client app vandaan haalt. Ik weet bijvoorbeeld dat de domme X terminals die aan de server hingen extreem weinig processor kracht hadden. Ook een antieke computer als een SGI Indy met een 100Mhz R4000 kon probleemloos alle X apps weergeven die remote draaide. Logisch ook, want de app zelf draaid helemaal remote. Alleen de GUI draaid op de client.

Een volwaardige applicatie heeft echter ook wat nadelen, om een normale applicatie te draaien heb je behoorlijk wat meer serverpower nodig dan dat je een groot gedeelte aan de client overlaat (zeker met een taal als PHP waar een request maar een zeer korte levensduur heeft).

Inderdaad, maar PHP gebruik je natuurlijk nooit voor (grote) applicaties. Een groot gedeelte van de server kracht die je voor de applications nodig hebt zit hem gewoon in de business/operationele logic
van die app, en niet in het feit via welke techniek het loopt.

Als men dus inderdaad naar rich web apps toe wil (wat dus wel gaat gebeuren, zie ook bijvoorbeeld recente posts op de FP), dan zullen ook platformen gebasseerd op ASP.NET of J2EE niet meer 5000 users op een 2Ghz servertje kunnen hebben.

[Verwijderd]

Mithrandir schreef op donderdag 27 oktober 2005 @ 00:05:
[...]
Voor mijn gevoel schets je een probleem wat er eigenlijk helemaal niet is; het web wordt niet 'misbruikt' voor te 'zware' applicaties.

Nu nog niet zo veel nee, maar het is wel de toekomst. Lees maar een beetje de news berichten door. Zomaar even een bericht waarin dit aspect te sprake komt: http://wwww.tweakers.net/nieuws/39235

Overigens is het tegenwoordig met bijvoorbeeld Ruby on Rails wel mogelijk om met een soort event-based applicatie te werken waarbij het framework voor een state zorgt (vs. stateless frameworks waarin iedere pagina alle informatie weer 'weg' is).

Het is niet zo dat het "wel mogelijk is met Ruby", bijna alle frameworks gaan daarheen als het primaire model. In ASP.NET zie je dit nu al sterk vertegenwoordigd, en Java EE (J2EE) gaat met JSF precies dezelfde kant op. Net zoals Swing vroeger een aparte download was voor Java is JSF dat nu. Echter in de volgende versie van Java EE zal JSF er standaard in zitten en dus het primaire model worden.

[Mithrandir]

Wat ik mij afvraag is wat je nu eigenlijk met rich clients bedoelt.

Waar zit het verschil tussen een rich client en een gewone applicatie? Noem je een soort console met GUI eromheen terwijl alle business-logic wordt uitgevoerd op een server een rich client? Noem je een word-applicatie die een bestand direct op de srever aanpast een rich client?

Ik denk dat we het wel eens kunnen zijn over het feit dat HTML en JavaScript op dit moment geen volwaardige vervanging zijn voor een programma als bijvoorbeeld Word.

[elevator]

Verwijderd schreef op donderdag 27 oktober 2005 @ 00:06:
Inderdaad, maar PHP gebruik je natuurlijk nooit voor (grote) applicaties. Een groot gedeelte van de server kracht die je voor de applications nodig hebt zit hem gewoon in de business/operationele logic
van die app, en niet in het feit via welke techniek het loopt.

Dat is niet waar denk ik - business logica zal zelden nog CPU bound zijn voor de meeste applicaties in de huidige tijd, echter de vele resources die besteed worden aan alle "rest" taken die een client applicatie heeft welke onderhouden moeten worden. Door deze overhead te distribueren verleg je op dat moment je probleem naar de client

Als men dus inderdaad naar rich web apps toe wil (wat dus wel gaat gebeuren, zie ook bijvoorbeeld recente posts op de FP), dan zullen ook platformen gebasseerd op ASP.NET of J2EE niet meer 5000 users op een 2Ghz servertje kunnen hebben.

Dat is natuurlijk nog maar de vraag - wat meer requests per client is nog heel wat anders dan een hele client omgeving in de lucht houden, om je een voorbeeld te geven - op een standaard Citrix server met dual CPU en 4gig geheugen kan je maar krap 40 concurrent users kwijt, dat zal voor webapplicaties andere cijfers geven denk ik

Ik ben het verder wel met je eens dat het wat vreemd is om client applicaties na te gaan bouwen in JavaScript maar ik denk dat je eerder naar virtualisatie software als bv. Softricity moet kijken voor een oplossing dan iets anders

[Verwijderd]

elevator schreef op donderdag 27 oktober 2005 @ 14:42:
[...]

Dat is niet waar denk ik - business logica zal zelden nog CPU bound zijn voor de meeste applicaties

Als dat zo was, dan had je voor desktop applicaties nooit meer een snellere CPU nodig, en zat ik niet meer de helft van de mijn tijd te 'verspillen' om mijn code te optimizen

op een standaard Citrix server met dual CPU en 4gig geheugen kan je maar krap 40 concurrent users kwijt, dat zal voor webapplicaties andere cijfers geven denk ik

Hangt sterk van de applicatie af. Ik heb een desktop applicatie'tje geschreven dat wat bestand naampjes genereerd. Het draait waarschijnlijk nog op een 7mhz 68000. Aan de andere kant doe ik de core van een analyse applicatie, en deze heeft 'toevallig' een web interface. De zwaarste full-analyze bewerking kan een kleine 2~3 minuten aan rekentijd kosten (=100% load op 1 CPU) en een dataset van rond de 100MB opleveren. Natuurlijk kunnen er niet 5000 van dergelijke users op 1 server.

Voor relatief simpele dingen kunnen web servers natuurlijk wel veel meer users aan. Er hoeft inderdaad geen hele omgeving per user opgezet te worden. Wat hashmaps geindexeerd op een ID (een session) en dat is het wel. Door het stateless design zijn er geen connections die opengehouden moeten worden. Wel moet potentieel voor elke request werk overnieuw worden gedaan wat in een statefull application niet zou hoeven.

Het hele punt is nu dat web applicaties juist MEER willen gaan doen dan de simpele interfaces. Google Gmail is al een voorbeeld. Zoals reeds eerder gezegd, frameworks als JSF spelen hier op in door serverside veel state te onthouden die na elke request gesynched wordt met de client.

[Verwijderd]

Mithrandir schreef op donderdag 27 oktober 2005 @ 00:33:
Wat ik mij afvraag is wat je nu eigenlijk met rich clients bedoelt.

In deze context vooral remote applications waarbij een feature rich widget set gebruikt wordt. Denk daarbij gewoon aan alle widgets en componenten die in je standaard desktop toolkit zitten. Dropdown menu's, (modal) dialogs, splitter panes, tree's, tree-lists, tab panes, buttons met images, maar ook canvas componenten met (vector) drawing operations als paths, circles, squares, fills (solid, patterned) etc, affine transformations (rotate, scale, shear, translate, etc) alsmede compositioning met alpha effects etc. Denk hierbij bijvoorbeeld aan wat je kunt met Swing/Java 2D of SWT/JFace, etc.

Of een dergelijke applicatie dan ook serverside zware bewerkingen uitvoerd of niet staat hier eigenlijk los van. (e.g. ik kan met een simpele console interface een mpeg4 encoder aansturen die lood en lood zware berekeningen doet, terwijl een geavanceerde GUI als in outlook eigenlijk alleen een browser voor wat data-filetjes is)

Het X model voor remote applications wordt al een tijdje als obsolete gezien, maar het kan wel eens helemaal terug komen in een iets andere vorm. Tanenbaum beschreef dit effect als "Recycling of Concepts": changes in the technology may bring back some of the so-called "absolete concepts." For this reason, it is important to understand why a concept is obsolete and what changes in the environment might bring it back again.

[Mithrandir]

Waarom zou je dit via het web willen gaan doen? Wat kan de motivatie zijn? Volgens mij is het installeren van zo'n toolkit om het mogelijk te maken bijna evenveel werk als het installeren van een complete standalone applicatie. Waarom zou je dat dan niet doen?

_{Even in de een-gek-kan-meer-vragen-dan-tien-wijzen-kunnen-antwoorden modus}

[Verwijderd]

Mithrandir schreef op donderdag 27 oktober 2005 @ 23:53:
Waarom zou je dit via het web willen gaan doen?

Vraag het Google. Vraag het Microsoft. Vraag het Sun. Vraag het Accountview.

Wat kan de motivatie zijn?

Onderhoud. Onmiddelijk de nieuwste versie voor iedereen; geen patches rond hoeven te sturen. Modellen voor het verhuren van software: afrekenen per minuut of per gebruikte funtie, etc.
Voor software die veel CPU kracht nodig heeft is het tevens een manier om die CPU power extern te betrekken: zelf niet meer een snellere CPU hoeven te kopen voor die ene app, maar gewoon je app provider mailen en vragen of ie ze meer CPU resources aan jouw login willen toekennen (tegen betaling natuurlijk).

Met dat laatste heb ik persoonlijk ervaring. Voor onze applicatie kopen we steeds snellere servers erbij. Onze klanten krijgen dus steeds betere performance, zonder dat ze zelf nieuwere hardware hebben gekocht.

Volgens mij is het installeren van zo'n toolkit om het mogelijk te maken bijna evenveel werk als het installeren van een complete standalone applicatie.

Dat is NIET zo. In het geval van X komt al elk gangbaar desktop OS met deze omgeving: Mac OS X, Linux, BSD, Sun OS, ze komen allemaal met een omgeving om X "weer te geven". Het enige desktop OS dat de X "viewer" niet standaard heeft is Windows, maar hiervoor is het slechts 1 malig 1 enkele download. Je hebt X "viewers" van meerdere aanbieders, en deze geven perfect elk remote X programma weer.

Waarom zou je dat dan niet doen?

Omdat je die X viewer maar 1 keer installed of helemaal niet installed omdat je hem al hebt. Aparte programma's moet je elke keer weer overnieuw installen.

Installeer jij dus meer dan 1 programma per computer, dan heeft deze aanpak al voordelen voor je.

Maar dit topic is eigenlijk niet bedoeld om te bediscuseren of remote applications met een rich interface wel zin hebben. Daar gaan al honderden topic over, en iedereen is er wel over uit dat deze er (meer) gaan komen.

Het punt is alleen, welke techniek gaan we er voor gebruiken? Breiden we de web techniek er voor uit (Struts, JSF, Spring-MVC, Tapestry, ASP.NET, etc) of stoffen we er de oude statefull modellen voor af (X Window, Citrix Metaframe, Windows TS, etc) en passen we deze meer aan voor een web omgeving ipv een lan.

[The Eagle]

Nou weet ik niet zoveel van X server af - maar als ik me niet vergis benader je dat vooral middels een telnet sessie. En daar zit hem de grootste bottleneck; telnet stuurt namelijk ieder karakter in een apart pakketje (bijv TCP/IP) over. Komt dus een flinke overhead bij kijken, en is dus niet echt rendabel - vandaar ook dat het zoveel bandbreedte vreet. Daar komt nog bij dat je tegenwoordig veel data in een binair formaat gehouden wordt; als je dat eerst nog moet converteren naar ASCII, scheelt je dat ook weer in performance.
True, het werkt wel (en op LAN's vaak zelfs prima), maar handig en economisch is anders

_{Ik kan hier ook wal nog schip raken zodat ik zojuist een klok-klepel verhaal heb getypt - in dat geval mijn excuses daarvoor}

[KC_Kaas]

Ik ben het met henk eens. Waarom het wiel opnieuw uitvinden. X-server was ontworpen met in het achterhoofd dan meerdere gebruikers tegelijkertijd aplicaties zouden draaien vanaf de server. Vroeger over het lokale netwerk, maar met de huidige internet snelheden en prijzen zou het ook prima kunnen werken via het internet. Verder heeft het een flink aantal voordelen, het is veilig (het werkt niet via telnet...), het is relatief stabiel en nog makkelijk te onderhouden ook.

Wel zou ik persoonlijk toch zeker wel twijfelen voordat ik ook mijn pc als terminal zou gaan gebruiken. Ik vind de gedachte dat al mijn programma's, documenten, foto's, enz allemaal op de server staan van mijn provider (nu nog niet maar in de toekomst zou dit natuurlijk wel mogelijk zijn). Je maakt je op die manier natuurlijk wel erg afhankelijk van een bepaalde (commerciële) party. Wanneer ze storing hebben aan de server of je tijdelijk geen internet hebt, dan je spullen / apps mooi op die server, maar dan kan je er natuurlijk niet bij komen. Verder kan de provider ineens besluiten om de kosten te verhogen en dan is het dus 'slikken of stikken'. Ook erg lijkt het me wanneer ze gaan bijhouden wat je allemaal uitspookt op je pc (HUN pc), dan kunnen ze je mooi reclame op 'maat' sturen...


[offtoppic]
Hee Henk, jij bent toch niet de henk die ik denk dat je bent toch. Je weet wel, die gene met de 6,7 voor zijn continue wiskunde?
[/offtoppic]

[ Voor 7% gewijzigd door KC_Kaas op 28-10-2005 00:53 ]

[MSalters]

Vergeleken met X is Windows 3.11 state of the art. X is een rampzalig protocol; het werd geteisterd door memory leaks. Dat is er nu wel zo'n beetje uit, maar de enige goede reden dat het nog gebruikt wordt is backwards compatibility. Volgens mij gebruikt OSX native geen X, en dat is voor een Unix OS toch veelzeggend.

[Verwijderd]

KC_Kaas schreef op vrijdag 28 oktober 2005 @ 00:50:

[offtoppic]
Hee Henk, jij bent toch niet de henk die ik denk dat je bent toch. Je weet wel, die gene met de 6,7 voor zijn continue wiskunde?
[/offtoppic]

[offtoppic]
Uhm... ik had een 6 voor continue wiskunde destijds, iniedergeval das het cijfer dat op mij propedeuse staat, dus wellicht dat je iemand anders in gedachten hebt? Anyway, tentamen heb ik in 2000 gedaan, als 1 van mijn laatste vakken.
[/offtoppic]

[Verwijderd]

Voor alle mensen in deze thread voor wie web applications zo iets raars en onbekends is:

http://wwww.tweakers.net/nieuws/39649