[AJAX] taal? library? api? of techniek?

[funkwurm]

In dit forum komt natuurlijk geregeld iets over AJAX langs, je kunt er dan ook erg mooie dingen mee. Maar mij valt op dat er vaak over AJAX gesproken wordt alsof het een programmeertaal op zich is. Nou ben ik meer van het client-side programmeren, dus misschien is mijn beeld scheef, maar jongens, AJAX is toch alles behalve een programmeertaal?

Het staat voor Asychronus Javascript And XML, en voor wat ik begrijp is het 1 object in javascript geheten XMLHttpRequest (ActiveX-varianten daar gelaten) met een aantal methods en properties om de boel in goede banen te leiden zonder dat de gebruiker een pagerefresh ervaart.

And that's really all there is to it... Je kunt geen AJAX programmeren, ik las net een topic van iemand die de oplossing graag zonder AJAX zou zien omdat hij geen andere talen dan PHP wil leren, bedoelt hij dat hij geen javascript wil leren?

Ik kan me ook niet voorstellen dat jullie zo verwend zijn door de libraries en API's die de client-side scripting voor je uitpoept dat jullie je niet meer realiseren dat AJAX 1 object is waarmee je 1 techniek kunt toepassen, dus begin ik aan dan maar aan m'n eigen beeld te twijfelen. Is dit puur het taalgebruik onder serverside programmers? Ben ik dan de enige die zich eraan stoort?

No hard feelings, maar ik gooi het graag even in de groep

edit:
Schrikt van tijd die verschijnt na posten, doet raam open, ziet straatlampen weer uit gaan...

[ Voor 3% gewijzigd door funkwurm op 14-07-2007 04:56 ]

[aex351]

AJAX, een afkorting, is wat de afkorting betekend. Ajax is dus geen programmeertaal, maar een techniek dat je middels programmeren kan toepassen.

[ATS]

Op zich heb je (TS) wat mij betreft gelijk, en ik denk ook dat er inderdaad mensen zijn die denken dat het een soort nieuwe taal is of iets dergelijks. Het begrip dekt echter wel meer dan alleen het XMLHttpRequest object. Het dekt een manier van werken, een manier van webapplicaties maken. Het is daarmee ook een manier van denken over webapplicaties geworden: het worden ook veel meer applicaties in plaats van pagina's. AJAX slaat daarmee wat mij betreft ook op het op een inteligente manier verdelen van taken tussen de client en de server. Het is het XMLHttpRequest object wat dat client-side mogelijk maakt, maar er komt natuurlijk veel meer bij kijken dan dat.

Kortom: ik zou het een paradigma willen noemen.

* ATS geeft overigens vaak geen XML maar JSON terug in een request.

[ Voor 3% gewijzigd door ATS op 14-07-2007 06:33 ]

[dingstje]

ATS schreef op zaterdag 14 juli 2007 @ 06:32:
Op zich heb je (TS) wat mij betreft gelijk, en ik denk ook dat er inderdaad mensen zijn die denken dat het een soort nieuwe taal is of iets dergelijks. Het begrip dekt echter wel meer dan alleen het XMLHttpRequest object. Het dekt een manier van werken, een manier van webapplicaties maken. Het is daarmee ook een manier van denken over webapplicaties geworden: het worden ook veel meer applicaties in plaats van pagina's. AJAX slaat daarmee wat mij betreft ook op het op een inteligente manier verdelen van taken tussen de client en de server. Het is het XMLHttpRequest object wat dat client-side mogelijk maakt, maar er komt natuurlijk veel meer bij kijken dan dat.

Kortom: ik zou het een paradigma willen noemen.

* ATS geeft overigens vaak geen XML maar JSON terug in een request.

Jij doelt op Web 2.0, wat mogelijk gemaakt kan worden door Ajax.

[ATS]

dingstje schreef op zaterdag 14 juli 2007 @ 06:34:
Jij doelt op Web 2.0, wat mogelijk gemaakt kan worden door Ajax.

Nee, dat doe ik niet. Web 2.0 houdt voor mij veel meer in dan dat. Web 2.0 heeft voor mij veel meer te maken met content en de interactie met je gebruikers. Web 2.0 gaat over user-generated content en communities. AJAX is daarin een techniek die je kan toepassen om sites interactiever te maken en een betere belevenis te bieden aan je gebruikers, waardoor je ze misschien ook beter vast kan houden en ze beter in staat kan stellen om ook daadwerkelijk hun input te leveren. Je kan echter ook "Web 2.0" dingen bouwen zonder AJAX te gebruiken. Ik zeg overigens niet dat ik Web 2.0 een nuttige term vind; ik vind het eigenlijk nogal gehyped.

[ Voor 4% gewijzigd door ATS op 14-07-2007 06:54 ]

[Niemand_Anders]

Ajax is inderdaad niet zo zeer een programmeer taal, maar eerder een manier van werken. Ajax stelt je in staat om snel beperkte informatie naar een webserver te sturen of juist juist een html sectie te updaten. Ik zie ajax dan ook eerder als een soort van webservice.

Waarom hebben een aantal programmeurs dan toch bezwaren tegen ajax? Voordat ajax op het toneel verscheen gebruikte de meeste programmeurs javascript voor een snelle controle van een formulier. Heeft zo'n iemand geen javacsript of staat deze uit, dan heeft deze persoon misschien een extra round trip.Met de komst van ajax is een gedeelte van de website naar de browser kant verschoven. Dat brengt extra complexiteit met zich mee (denk aan het debuggen van code) waardoor je verliest sneller het overzicht wanneer iets wordt uitgevoerd. Nog los van het feit dat elke browser weer anders werkt. Ajax implementaties werken dan ook alleen goed bij websites waarbij eerst alles goed wordt uitgewerkt, echter de meeste websites worden vaak geprogrammeerd via de agile methode, ookwel bekend als ik schrijf wel wat en we zien wel of het werkt..

Vaak worden ajax oplossingen gekozen omdat het kan en niet omdat het noodzakelijk is (een echte toevoeging). En dat geeft dan meestal weer het probleem dat als een iets oudere browser worden gebruikt de website niet meer werkt. Waarschijnlijk trekt dit wel weer recht als de ajax hype weer een beetje over is.

Enkele jaren werd ook ineens xml gehyped als het ultieme opslag formaat. Gelukkig zijn een hoop bedrijven toch weer terug op aarde gekomen en bieden hun exports aan zoals EDI of CSV. De nieuwe hype voor exports zijn embedded databases zoals sqlite en firebirdsql.

[Verwijderd]

AJAX is niks meer dan wat Javascript waarmee je een nieuwe pagina opvraagt in een deel van je code, waarbij je zelfs GET variablen kan meegeven, en alles wat het doet is het resultaat van die pagina eruit halen. Niets meer als dat eigenlijk.

[Creepy]

Verwijderd schreef op zaterdag 14 juli 2007 @ 10:54:
AJAX is niks meer dan wat Javascript waarmee je een nieuwe pagina opvraagt in een deel van je code, waarbij je zelfs GET variablen kan meegeven, en alles wat het doet is het resultaat van die pagina eruit halen. Niets meer als dat eigenlijk.

Je vergeet voor het gemak wel heel de serverside kant van het verhaal, want ook dat is onderdeel van het geheel.

[JKVA]

Verwijderd schreef op zaterdag 14 juli 2007 @ 10:54:
AJAX is niks meer dan wat Javascript waarmee je een nieuwe pagina opvraagt in een deel van je code, waarbij je zelfs GET variablen kan meegeven, en alles wat het doet is het resultaat van die pagina eruit halen. Niets meer als dat eigenlijk.

Precies. Ik stoor me ook vrij veel aan de term AJAX en de manier hoe deze (door niet-ajacieden) gebruikt wordt alsof het a) heilig is, b) altijd werkt, c) gemakkelijk is, d) etcetera.

Toen ik het een jaar of 5 geleden voor het eerst in een project gebruikte, noemden we het gewoon een berichtje naar de server (ff wat gegevens ophalen of posten). Wij dachten er toen net zo simpel over als veel mensen nu. Gevolg, totaal onleesbare code door de asynchrone aard van deze techniek (overal callbacks die rond refereren), slechtere performance omdat netwerkverkeer simpelweg trager is dan in process verwerking en veel grotere complexiteit omdat elke pagina een applicatie op zich wordt.

Tegenwoordig kom ik veel mensen tegen die zich dan met AJAX gerelateerde zaken gaan lopen bemoeien na één Dojo of prototype.js tutorial gedaan te hebben en gaan doen alsof ze doorhebben tegen welke problemen je aan kunt lopen door AJAX te pas en te onpas te gebruiken.

Nee, ik ben niet echt blij met de term AJAX.

[tss68nl]

Maakt het uit? Nieuw naampje voor wat we al jaren deden. En op zich handig dat iemand de tijd heeft genomen om er een standaard library voor in de markt te zetten.

En sjah, AJAX programmeren, AJAX gebruiken, AJAX implementeren...ze noemen het maar wat ze willen, ik kan me er niet zo aan storen eerlijk gezegd.

[Verwijderd]

Niemand_Anders schreef op zaterdag 14 juli 2007 @ 09:44:
echter de meeste websites worden vaak geprogrammeerd via de agile methode, ookwel bekend als ik schrijf wel wat en we zien wel of het werkt..

"ik schrijf wel wat en we zien wel of het werkt" heeft helemaal niets met agile software development te maken!

quote: http://en.wikipedia.org/wiki/Agile_software_development

There are a number of agile software development methods; most attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. In many cases, software is released at the end of each iteration. This is particularly true when the software is web-based and can be released easily. Regardless, at the end of each iteration, the team re-evaluates project priorities.

[JKVA]

Verwijderd schreef op zaterdag 14 juli 2007 @ 11:55:
[...]
"ik schrijf wel wat en we zien wel of het werkt" heeft helemaal niets met agile software development te maken!
[...]

Ja, dat weet jij, dat weten mensen die er serieus mee bezig zijn (zoals bij Ericsson), maar de meeste developers zien agile als: "We doen maar wat, zonder architectuur, zonder documentatie, zonder kwaliteit." en hebben niet door dat je met agile ontwikkeling JUIST kwaliteit kunt waarborgen.

Zie RUP: Dat is dus echt niet iets van "we doen maar wat", integendeel, RUP is zwaar bloated juist heel uitgebreid en houdt met veel dingen rekening. Voor het gemiddelde project in NL misschien zelfs TE veel.

Bovendien doen relatief veel bedrijven aan een vorm van agile, maar vallen helemaal terug als blijkt dat bijvoorbeeld de klant niet de discipline kan opbrengen voor een agile methodiek of als de stress erin schiet. Dan is het bij de meeste projecten snel gedaan met agile.

[ Voor 3% gewijzigd door JKVA op 14-07-2007 17:35 ]

[GX]

JKVA schreef op zaterdag 14 juli 2007 @ 12:15:
[...]

Ja, dat weet jij, dat weten mensen die er serieus mee bezig zijn (zoals bij Ericsson), maar de meeste developers zien agile als: "We doen maar wat, zonder architectuur, zonder documentatie, zonder kwaliteit." en hebben niet door dat je met agile ontwikkeling JUIST kwaliteit kunt waarborgen.

Eenieder die de term Agile durft te gebruiken voor zijn aanpak dient ook gewoon te weten wat het precies inhoud. Wat jij beschrijft is "prutsen" en dat heeft bar weinig te maken met welke methode dan ook. Daarnaast is Agile enkel een verzamelterm voor vele andere methodes

[ Voor 10% gewijzigd door GX op 14-07-2007 13:20 ]

[Verwijderd]

AJAX is wat mij betreft een techniek om van webpagina's webapplicaties te maken. De basis zit hem natuurlijk in het uitvoeren van asynchrone requests. En als je dat dan met Javascript doet, en data in XML formaat terugkrijgt, dan kun je dat AJAX noemen.

Die je het met iets anders dan Javascript, bijvoorbeeld met een ActiveX object, een Java applet of een Flash object, dan is het geen AJAX, maar zit er nog steeds dezelfde gedachte achter. Datzelfde geldt als je geen XML opvraagt, maar JSON of plain text.

De term AJAX is echter een soort verzamelwoordje geworden. Dat gebeurt gewoon. DHTML is ook zoiets.

• Het is geen taal. Javascript is een taal, XML is eigenlijk ook geen taal. AJAX ook niet.
• Het is geen API, er is immers eigenlijk geen officiele interface. Je zou ook met Javascript een script element aan een document kunnen toevoegen, daar een of ander XML document mee laden, en daar vervolgens iets mee doen. Je hebt geen XMLHTTPRequest nodig om het AJAX te kunnen noemen. XMLHTTPRequest is wel deel van een API, maar geen vereiste.
• Het is geen library. Er zijn immers geen vastgelegde regels, functies of wat dan ook.
• Het is dus een techniek. Een verzameling van een taal, een formaat en een manier van werken.

[sky-]

Ook wordt tegenwoordig AJAX en "Web 2.0" ook steeds met elkaar verbonden. Alsof "Web 2.0" AJAX is. (Overigens vind ik Web 2.0 maar een onzinterm, zelfde voor ajax..)

[Niemand_Anders]

Het probleem dat veel programmeurs hebben met agile development is dat ze het namelijk combineren met extreme programming. Agile development waar bij elke ronde het systeem wordt ge-evalueerd en op basis daarvan het design wordt bijgewerkt is helaas een zeer zeldzaam iets.

Agile development heeft theoretisch inderdaad niets met aankl#ten te maken, maar in de praktijk is dat helaas vaak wel het resultaat. Zeker in web application development kan de agile methode zeker bijdragen aan een goed resultaat omdat opdrachtgevers vaak niet goed weten wat ze precies willen en daardoor tijdens development requirements regelmatig veranderen. Veel developers kunnen hier niet goed tegen en daarom wordt op een gegeven moment gestopt met het maken van UML diagrammen, documentatie, etc.

Zelf heb ik al zeer veel moeite om mijn developers na een iteratie ronde zover te krijgen dat ze toch eerst gaan designen en documenteren voordat ze visual studio weer opstarten. Regelmatig krijg ik de opmerking 'Maar waarom zou ik nog documenteren? Volgende week moet het toch weer anders.." naar mijn hoofd geslingert. Op (externe) projecten waar ik niet continue de regie in handen heb is dat helemaal lastig.

Mijn definitie van agile development is dus in zakere mate gewijzigd. Dat had ik er misschien maar beter even bij kunnen vermelden.

Sorry.

[JKVA]

GX schreef op zaterdag 14 juli 2007 @ 13:18:
[...]
Eenieder die de term Agile durft te gebruiken voor zijn aanpak dient ook gewoon te weten wat het precies inhoud.

Helaas gebeurt dat niet overal. Ik hoor overal te pas en te onpas de term agile vallen, zoals in dit topic, terwijl het 9 van de 10 keer niet met agile te maken heeft of juist het tegenovergestelde is van agile

Wat jij beschrijft is "prutsen" en dat heeft bar weinig te maken met welke methode dan ook. Daarnaast is Agile enkel een verzamelterm voor vele andere methodes

Ik doel ook op prutsen. Ik zeg ook niet dat agile op deze manier werkt. Integendeel, ik ben zelfs erg gecharmeerd van XP, RUP, Scrum, etc. Sterker nog, het bedrijf waar ik werk, heeft zijn eigen RUP variant en promoot dat (terecht) heel sterk.

In mijn optiek mag een methodologie zichzelf agile noemen als het a) op een iteratieve/evolutionaire manier werkt en b) veranderingen gedurende EN NA het project gemakkelijk maakt. Als het dat niet doet, is het absoluut niet agile.

Maar goed, genoeg over agile...

[JKVA]

k8skaaay schreef op zaterdag 14 juli 2007 @ 13:35:
Ook wordt tegenwoordig AJAX en "Web 2.0" ook steeds met elkaar verbonden. Alsof "Web 2.0" AJAX is. (Overigens vind ik Web 2.0 maar een onzinterm, zelfde voor ajax..)

http://en.wikipedia.org/wiki/Web_2 eerste alinea is wat mij betreft een goede omschrijving van Web 2.0. Web 2.0 is wat mij betreft hetzelfde als meer en intensiever internet gebruiken voor veel meer toepassingen dan vroeger. Wat je daaronder verstaat, AJAX/RIA, 2nd life, blogs, e business/ebay/marktplaats, whatever, moet je zelf weten. Er bestaat geen definitie em Web 2.0 is (net als AJAX) een buzzword.

Ze spreken al over Web 3.0 en Web 4.0...

[Sircuri]

JKVA schreef op zaterdag 14 juli 2007 @ 12:15:

Zie RUP: Dat is dus echt niet iets van "we doen maar wat", integendeel, RUP is zwaar bloated en houdt met veel te veel dingen rekening voor het gemiddelde project in NL.

Nog nooit een boek gelezen over RUP zeker. Mensen die dit beweren zoals jij het hierboven bescrhijft, snappen inderdaad niet wat RUP is. RUP is een grote bak met taken, activiteiten, documenten en nog veel meer. Je kiest uit die bak alles wat je nodig denkt te hebben in je project. Niet meer en zeker niet minder.

[Hydra]

JKVA schreef op zaterdag 14 juli 2007 @ 12:15:
[...]

Ja, dat weet jij, dat weten mensen die er serieus mee bezig zijn (zoals bij Ericsson), maar de meeste developers zien agile als: "We doen maar wat, zonder architectuur, zonder documentatie, zonder kwaliteit." en hebben niet door dat je met agile ontwikkeling JUIST kwaliteit kunt waarborgen.

Dan moet je niet gaan roepen dat iemand volgens een agile methode ontwikkeld als ze dat ook duidelijk niet doen. Wat Niemand_Anders noemt, noemt men "Cowboy coding".

Niemand_Anders schreef op zaterdag 14 juli 2007 @ 14:05:
Zelf heb ik al zeer veel moeite om mijn developers na een iteratie ronde zover te krijgen dat ze toch eerst gaan designen en documenteren voordat ze visual studio weer opstarten. Regelmatig krijg ik de opmerking 'Maar waarom zou ik nog documenteren? Volgende week moet het toch weer anders.." naar mijn hoofd geslingert. Op (externe) projecten waar ik niet continue de regie in handen heb is dat helemaal lastig.

Klinkt meer als mismanagement van requirements dan als developers die het verkeerd doen. Er is geen enkele methode die ervoor zorgt dat developers niet gedemotiveerd raken als het "volgende week toch weer anders moet".

JKVA schreef op zaterdag 14 juli 2007 @ 14:21:
http://en.wikipedia.org/wiki/Web_2 eerste alinea is wat mij betreft een goede omschrijving van Web 2.0. Web 2.0 is wat mij betreft hetzelfde als meer en intensiever internet gebruiken voor veel meer toepassingen dan vroeger. Wat je daaronder verstaat, AJAX/RIA, 2nd life, blogs, e business/ebay/marktplaats, whatever, moet je zelf weten. Er bestaat geen definitie em Web 2.0 is (net als AJAX) een buzzword.

Ze spreken al over Web 3.0 en Web 4.0...

So? Marketing is belangrijk. Dat Web 2.0 op zich technisch gezien niet erg veel voorstelt, prima, maar het verkoopt wel lekker.

En verder: dat gebruik van generaties is ook niks nieuws. Iedereen kent 3GL/4GL neem ik aan?

Sircuri schreef op zaterdag 14 juli 2007 @ 15:16:
Nog nooit een boek gelezen over RUP zeker. Mensen die dit beweren zoals jij het hierboven bescrhijft, snappen inderdaad niet wat RUP is. RUP is een grote bak met taken, activiteiten, documenten en nog veel meer. Je kiest uit die bak alles wat je nodig denkt te hebben in je project. Niet meer en zeker niet minder.

Inderdaad. Je pakt de tools om een bepaalde taak te doen. Je gaat niet de taak opvullen (/bloaten) zodat het bij je tools past.

[ Voor 69% gewijzigd door Hydra op 14-07-2007 17:00 ]

[JKVA]

Hydra schreef op zaterdag 14 juli 2007 @ 16:55:
[...]
Dan moet je niet gaan roepen dat iemand volgens een agile methode ontwikkeld als ze dat ook duidelijk niet doen. Wat Niemand_Anders noemt, noemt men "Cowboy coding".
[...]

Dat roep ik ook niet. Ik geef alleen aan dat ze volgens eigen zeggen Agile ontwikkelen, maar dat eigenlijk bullshit is.

[...]
Klinkt meer als mismanagement van requirements dan als developers die het verkeerd doen. Er is geen enkele methode die ervoor zorgt dat developers niet gedemotiveerd raken als het "volgende week toch weer anders moet".
[...]

Jammergenoeg uit ervaring: "Helemaal mee eens."

[...]
So? Marketing is belangrijk. Dat Web 2.0 op zich technisch gezien niet erg veel voorstelt, prima, maar het verkoopt wel lekker.

En verder: dat gebruik van generaties is ook niks nieuws. Iedereen kent 3GL/4GL neem ik aan?
[...]

Jammergenoeg zijn de scheidslijnen bij 3GL/4GL vrij duidelijk, maar worden op front end gebied termen dwars door elkaar gebruikt. Is AJAX met JSON AJAX? Wat is Web 2.0? Etc...

Wat ze technisch onder een woord vatten voorstelt boeit me niet echt veel, aangezien deze woorden toch vanuit de techniek opbloeien en de techniek dus niet meer vernieuwend is. Het is alleen wel fijn als dit op een consistente manier gebeurt. (ik gebruik bijv. bijna nooit de term Web 2.0)

[...]
Inderdaad. Je pakt de tools om een bepaalde taak te doen. Je gaat niet de taak opvullen (/bloaten) zodat het bij je tools past.

En dan kom je bij bedrijven die leuke bedrijfsbrede policies hebben hiervoor waardoor je uitkomt op een enorme overhead voor je kleine projectje van 4 maanden/4 developers. Maar ja, het is de standaard binnen het bedrijf, dus projectmanagement stelt het verplicht, anders ben je in hun optiek aan het "cowboy coden".

Ps. Misschien had ik de term bloated niet moeten noemen. Ik ken RUP en waardeer het absoluut, dus bij dezen trek ik de term "bloated" terug. Bloated klinkt te negatief.

[aex351]

Vraag me af wanneer web 3.0 gereleased gaat worden.

[JKVA]

Overigens, ik bedenk me dat ik over het hele AJAX gebeuren wel iets positiever ben dan ik in eerste instantie dacht. Toen ik het voor het eerst gebruikte, waren er nog geen mooie frameworks en (zover ik weet) ondersteuning in browsers anders dan IE.

Tegewoordig, ik denk deels door de hype, zijn er mooie frameworks, zoals prototype, DWR en zo, die het leven veel gemakkelijker maken. Bovendien wordt het door andere browsers dan IE ondersteund en dat was zonder hype denk ik niet gelukt.

[crisp]

Verwijderd schreef op zaterdag 14 juli 2007 @ 13:34:
AJAX is wat mij betreft een techniek om van webpagina's webapplicaties te maken. De basis zit hem natuurlijk in het uitvoeren van asynchrone requests. En als je dat dan met Javascript doet, en data in XML formaat terugkrijgt, dan kun je dat AJAX noemen.

Die je het met iets anders dan Javascript, bijvoorbeeld met een ActiveX object, een Java applet of een Flash object, dan is het geen AJAX, maar zit er nog steeds dezelfde gedachte achter. Datzelfde geldt als je geen XML opvraagt, maar JSON of plain text.

De term AJAX is echter een soort verzamelwoordje geworden. Dat gebeurt gewoon. DHTML is ook zoiets.

Dat is een erg letterlijke benadering van AJAX, de grote vraag is of Jesse James Garrett dat ook voor ogen had toen hij met die term kwam. Als ik het Adaptive Path Ajax artikel lees denk ik van niet

Persoonlijk denk ik dat AJAX inmiddels een paradigma is geworden en dat het nogal onzinnig is om elke practice onder dat paradigma andere naampjes te gaan geven zoals SJAX, AJAJ, SJAJ etcetera. En anders mag iemand een betere naam gaan verzinnen voor het paradigma van al deze technieken

Overigens is de XML in XMLHttpRequest ook enkel toegevoegd om het indertijd wat meer 'spice' te geven; XMLHttpRequest gaat voornamelijk om HTTP, XML is maar bijzaak...

[ Voor 4% gewijzigd door crisp op 14-07-2007 22:54 ]

[funkwurm]

Blimey, ik heb een beste discussie los doen barsten. De term agile kende ik niet maar ik ben altijd bereidt te leren.

Ik sluit me aan bij wat crisp zegt, AJAX is de verzamelterm geworden voor elke vorm van server-requests doen zonder de UI te verstoren. Wat bij betreft zijn daarmee zelfs het hidden iframe, het toevoegen van een <script>-tag aan het DOM en het laden van een plaatje dat een cookie zet vormen van AJAX.

AJAX is nu eenmaal veel beter uitspreekbaar en onthoudbaar dan alle andere ontermen. Het is daarmee nog steeds wel een techniek. Cheatah zegt dat het daarmee ook "Een verzameling van een taal, een formaat en een manier van werken" is, maar dat is het volgens mij niet. Het is onderdeel van de taal javascript, wat je met een verzameling van een taal bedoelt begrijp ik niet. Het formaat staat los van het gebruik van AJAX. XML, JSON, plain text, csv, het kan allemaal. Een "manier van werken" heet volgens mij een methode, en er zijn verschillende methodes om de AJAX techniek toe te passen (synchroon, asynchroon, queueing, geen queueing, etc).

Verder zeg je dat XML ook geen taal is, waar staat de L in XML dan voor? OK, we hadden bij AJAX ook gezegd dat je niet meer letterlijk naar de afkorting moet kijken, dus waarom bij XML wel... maar dan nog, XML is een taal om een datastructuur voor mens en machine leesbaar en bovenal interpreteerbaar te maken. Het is geen programmeertaal, maar zeker wel een taal.

tss68nl schreef op zaterdag 14 juli 2007 @ 11:46:
Maakt het uit? Nieuw naampje voor wat we al jaren deden. En op zich handig dat iemand de tijd heeft genomen om er een standaard library voor in de markt te zetten.

En sjah, AJAX programmeren, AJAX gebruiken, AJAX implementeren...ze noemen het maar wat ze willen, ik kan me er niet zo aan storen eerlijk gezegd.

Deze post valt mij op, en zo kom ik ook op de reden dat ik mij hier aan stoor en dit topic open. Waar programmeurs in dit forum niet zelden afgeven op MySQL, php en javascript omdat het "smerig" is, "onzorgvuldig", "weakly typed" en wat niet al, hebben genoeg mensen er in het gewone leven blijkbaar geen moeite mee om dit soort taalslordigheden te maken. Mind you, hoeveel gaat er in het bedrijfsleven mis of kost onnodig extra tijd/geld omdat de communicatie tussen betrokken partijen gebreken vertoont?

Als ik dan toch even terug kom op de agile-methode. Voor wat ik er van begrijp poogt deze er voor te zorgen (indien juist toegepast) dat er vaak checks plaatsvinden om met demand te bekijken of alle partijen nog op 1 lijn zitten, elkaar goed begrepen hebben sinds de laatste keer en er dus niet straks grote teleurstellingen zullen zijn. Mijns inziens dus een methode waarbij dus eigenlijk wordt aangenomen dat communicatie tussen partijen gebreken zal vertonen en je daar dus ook maar beter rekening mee kunt houden.

En uit ervaring weet ik dat ICT'ers en communicatie ook inderdaad lang niet altijd hand-in-hand gaan, vrouwelijke ICT'ers laat je horen

[ Voor 6% gewijzigd door funkwurm op 14-07-2007 23:33 ]

[Verwijderd]

funkwurm schreef op zaterdag 14 juli 2007 @ 23:30:

Ik sluit me aan bij wat crisp zegt, AJAX is de verzamelterm geworden voor elke vorm van server-requests doen zonder de UI te verstoren. Wat bij betreft zijn daarmee zelfs het hidden iframe, het toevoegen van een <script>-tag aan het DOM en het laden van een plaatje dat een cookie zet vormen van AJAX.

Ik vind van niet. AJAX is een hulpmiddel om webpagina's "interactief" te maken. In feite bouw je dan meer een webapplicatie dan een webpagina. We zouden alles wel AJAX kunnen noemen, maar de naam slaat nergens op. Als je het een zegt, maar het ander bedoelt, zou je beter het ander bij zijn naam kunnen noemen. Maar de termen zijn een beetje op. Je kunt het "Interactive Web Pages" noemen, of "Dynamic Pages", of "Live Pages". Alles maar AJAX noemen is onzin.

AJAX is nu eenmaal veel beter uitspreekbaar en onthoudbaar dan alle andere ontermen. Het is daarmee nog steeds wel een techniek. Cheatah zegt dat het daarmee ook "Een verzameling van een taal, een formaat en een manier van werken" is, maar dat is het volgens mij niet. Het is onderdeel van de taal javascript, wat je met een verzameling van een taal bedoelt begrijp ik niet. Het formaat staat los van het gebruik van AJAX. XML, JSON, plain text, csv, het kan allemaal. Een "manier van werken" heet volgens mij een methode, en er zijn verschillende methodes om de AJAX techniek toe te passen (synchroon, asynchroon, queueing, geen queueing, etc).

Als je XML in de naam hebt, leg je daarmee het formaat vast. Zie mijn vorige punt. Dat iedereen alles wat requests doet naar een server AJAX gaat noemen is niet mijn fout. Ik stel alleen vast dat XML in de naam zit, en dat daarmee ofwel de naam niet klopt met wat men bedoelt, of men gebruikt iets waarvoor het niet bedoeld is.

Verder zeg je dat XML ook geen taal is, waar staat de L in XML dan voor? OK, we hadden bij AJAX ook gezegd dat je niet meer letterlijk naar de afkorting moet kijken, dus waarom bij XML wel... maar dan nog, XML is een taal om een datastructuur voor mens en machine leesbaar en bovenal interpreteerbaar te maken. Het is geen programmeertaal, maar zeker wel een taal.

Dat ben ik niet met je eens. Het is hooguit een formaat, dat regels vaststelt voor talen in dat XML formaat. Dat maakt XML zelf nog geen taal. Letters zijn geen taal. Leestekens zijn geen taal. Ze maken er wel deel van uit. Maar uiteindelijk is dit zwaar offtopic.

Het gaat erom dat de term AJAX vaak misbruikt wordt, en derhalve in veel situaties nergens meer op slaat. Tijd voor een nieuwe term.

[crisp]

Verwijderd schreef op zondag 15 juli 2007 @ 00:25:
[...]
Als je XML in de naam hebt, leg je daarmee het formaat vast. Zie mijn vorige punt. Dat iedereen alles wat requests doet naar een server AJAX gaat noemen is niet mijn fout. Ik stel alleen vast dat XML in de naam zit, en dat daarmee ofwel de naam niet klopt met wat men bedoelt, of men gebruikt iets waarvoor het niet bedoeld is.

Zie de links in mijn vorige reply; het is niet duidelijk of de 'X' in AJAX nu staat voor 'XML' of voor 'XMLHttpRequest' - het artikel van Jesse is daar niet helemaal consistent in. In het laatste geval moet je afgaan op wat 'XML' in XMLHttpRequest voor betekenis heeft, en dat is puur marketing geweest en heeft dus eigenlijk geen betekenis

Dat ben ik niet met je eens. Het is hooguit een formaat, dat regels vaststelt voor talen in dat XML formaat. Dat maakt XML zelf nog geen taal. Letters zijn geen taal. Leestekens zijn geen taal. Ze maken er wel deel van uit. Maar uiteindelijk is dit zwaar offtopic.

Het gaat erom dat de term AJAX vaak misbruikt wordt, en derhalve in veel situaties nergens meer op slaat. Tijd voor een nieuwe term.

Als je de term 'AJAX' als acroniem blijft zien dan slaat het inderdaad meestal nergens op en is het inderdaad tijd voor een nieuwe term of een herdefinitie van het acronym zelf (All JAvascript eXtra's ofzo )

[ATS]

Verwijderd schreef op zondag 15 juli 2007 @ 00:25:
[...]
Als je XML in de naam hebt, leg je daarmee het formaat vast. Zie mijn vorige punt. Dat iedereen alles wat requests doet naar een server AJAX gaat noemen is niet mijn fout. [...]

OK, dus volgens jou is AJAX onlosmakelijk verbonden met XML omdat het in de naam zit, toch? OK, dat is een standpunt. Ik ben het er niet mee eens, maar het is wel verdedigbaar. Echter, als je dan zegt:

[...]
Dat ben ik niet met je eens. Het is hooguit een formaat, dat regels vaststelt voor talen in dat XML formaat. Dat maakt XML zelf nog geen taal. Letters zijn geen taal. Leestekens zijn geen taal. Ze maken er wel deel van uit. Maar uiteindelijk is dit zwaar offtopic.

... dan spreek je jezelf m.i. tegen. Immers, omdat de X van XML in AJAX zit, gaat AJAX over XML, maar ondanks dat de L van "Language" in XML zit, is XML geen taal. Schiet mij maar lek.

M.i. is XML overigens een meta formaat, dat je kan gebruiken als structuur voor andere, meer specifieke data formaten of talen. Zelf is het in die opvatting dan ook geen taal (ondanks de L), maar ik ben dan ook van mening dat AJAX niet exclusief naar XML verwijst, dus dat lijkt me qua consistentie geen probleem.

[flowerp]

ATS schreef op zaterdag 14 juli 2007 @ 06:53:
[...]
Nee, dat doe ik niet. Web 2.0 houdt voor mij veel meer in dan dat. Web 2.0 heeft voor mij veel meer te maken met content en de interactie met je gebruikers. Web 2.0 gaat over user-generated content en communities.

Dus in jouw optiek was het oude usenet ook al Web 2.0? En die flauwe online homepage generators van providers rond 1997 ofzo was dus ook al Web 2.0? En De Digitale Stad?

Heeft Web 1.0 eigenlijk wel ooit echt bestaan? Zijn we niet gewoon begonnen met Web 2.0?

[Confusion]

JKVA schreef op zaterdag 14 juli 2007 @ 11:39:
Gevolg, totaal onleesbare code door de asynchrone aard van deze techniek (overal callbacks die rond refereren),

Alles is acceptabel voor het verbeteren van de user experience, want dat levert domweg geld op. Het is een kwestie van de flow heel goed documenteren.

Hydra schreef op zaterdag 14 juli 2007 @ 16:55:
Klinkt meer als mismanagement van requirements dan als developers die het verkeerd doen. Er is geen enkele methode die ervoor zorgt dat developers niet gedemotiveerd raken als het "volgende week toch weer anders moet".

Jawel, de methode: leer je developers dat dat zo zal zijn en leer ze defensief genoeg te programmeren, zodat die nieuwe requirements snel in het systeem te hangen zijn. Dat er zoiets als 'mismanagement van requirements' kan zijn, gaat uit van het idee dat je vantevoren je requirements vast kan stellen. Dat is gewoon zelden zo: er is altijd sprake van voortschrijdend inzicht en zeker bij innovatieve projecten kunnen er weleens radicale richtingswijzigingen zijn. Daar moet je vanaf dag 0 rekening mee houden. Alleen als je een bestaande applicatie vervangt, zal de functionaliteit vanaf dag 0 duidelijk zijn, en zelfs dan komt iemand halverwege op een lumineus idee dat de scope vergroot en drastische aanpassingen vereist, maar eigenlijk wel een verdomd goed idee is.

[flowerp]

funkwurm schreef op zaterdag 14 juli 2007 @ 23:30:
XML is een taal om een datastructuur voor mens en machine leesbaar en bovenal interpreteerbaar te maken. Het is geen programmeertaal, maar zeker wel een taal.

XML:

<c:choose>
   <c:if test="${foo.prop == true}" >
      <c:forEach items="${list.items}" var="item" >
         <c:out value="${item}" />
      </c:forEach>
   </c:if>

   <c:otherwise>
      <c:out value="${foo.bar}" />
   </c:otherwise>
</c:choose>

Dit is een stuk JSTL, een taal die de XML syntax gebruikt voor programmeer constructies.

En natuurlijk is dit niet bedoeld om echt een complete applicatie in te gaan programmeren. Het is slechts bedoeld om in een page layout kleine 'render' beslissingen te maken. Sommige mensen snappen echter niet altijd welke techniek waar voor bedoeld is en gaan dan hele stukken business logic midden in een view hiermee uitdrukken

Feitelijk is XML dus alleen een syntax, een soort meta taal. Door gebruik te maken van XML hoef je nooit meer zelf een tokenizer en syntax tree builder te schrijven. Ook hoef je geen grammar meer te ontwerpen voor je taal. Wel is het zeer aan te raden om een DTD of schema te maken, zodat "programma's" in jouw taal automatisch gevalideerd kunnen worden, en tools je kunnen helpen bij het schrijven ervan.

De semantiek van de taal die je in XML uitdrukt hangt af van de code die het verwerkt. Zo kan het gebruikt worden als algemene datastructuur (config files, documenten, plaatjes (SVG), of zelfs voor een DB), of voor dingen als het beschrijven van een page layout (XHTML, JSP documents, Facelets) en zelfs dus als programmeertaal (JSTL).

Daarbij is het soms primair bedoeld om door mensen geedit te worden (config files) en soms primair voor machine to machine communicatie (SVG).

MySQL, php en javascript omdat het "smerig" is, "onzorgvuldig", "weakly typed" en wat niet al, hebben genoeg mensen er in het gewone leven blijkbaar geen moeite mee om dit soort taalslordigheden te maken.

Het gaat er ook niet om of de mensen de taalslordigheden maken, maar of de taal voorzieningen biedt om ambiguïteit en fouten te voorkomen. Natuurlijke taal is daar niet zo goed in. De interpretatie van dergelijke talen is zeer, zeer context gevoelig. Binnen formele talen (losjes gezegd; 'computer talen') heb je de mogelijkheid om context vrije grammatica's op te stellen en de semantiek exact te definiëren. Des te strakker je het definieert, des te minder kans op ambiguïteit en fouten heb je.

Ongeacht de taal, zullen mensen gemiddeld even slordig zijn. De regels van de taal moeten mensen echter op deze slordigheden kunnen betrappen om problemen te voorkomen. Het SQL dialect van MySQL en de taal PHP zijn wat slordiger gedefinieerd dan bijvoorbeeld equivalenten als het SQL van PostGreSQL en de taal Java, C#, C++ etc.

Dwz, MySQL/PHP staat dus makkelijker toe dat de programmeur het ene opschrijft, maar het andere bedoeld. Een taal is daarbij natuurlijk altijd een abstractie van het geen in het hoofd van een persoon zit. Mensen zijn graag slordig en lui. Als de taal hen niet verplicht expliciet te zijn zullen ook weinigen dat doen. Bepaalde groepen mensen vinden het dus vervelend dat je in b.v. Java wat explicieter moet zijn, dus schrijven ze in het 'luie' PHP hun code. Als je het echter moet lezen is het andersom; wat bedoelde de programmeur hier nu? De code maakt het dikwijls dan niet duidelijk.

In natuurlijke talen heb je ook het verschijnsel dat sommige talen je dwingen dingen meer of minder expliciet uit te drukken. In het Nederlands is het vereist dat je enkelvoud of meervoud moet uitdrukken:

"Ik lees het boek." en
"Ik lees de boeken."

Je kunt het eenvoudigweg niet weglaten.

In bijvoorbeeld een taal als Japans is het helemaal niet vereist en is het van de context afhankelijk of je 1 of meerdere boeken leest:

"Watashi wa hon o yomu" (ik lees het boek)
"Watashi wa hon o yomu" (ik lees de boeken)
"Watashi wa hon o yomu" (ik lees een boek)

Mind you, hoeveel gaat er in het bedrijfsleven mis of kost onnodig extra tijd/geld omdat de communicatie tussen betrokken partijen gebreken vertoont?

Inderdaad, en tijdens de ontwikkeling van software is dit misschien wel 1 van de grootste problemen. Nu is het natuurlijk niet mogelijk om even van natuurlijke taal te wisselen. We gaan niet opeens allemaal op kantoor in het Chinees communiceren als blijkt dat het Chinees meer exacte definities van zaken vereist (wat niet zo is, maar stel).

Het is ook niet zonder reden dat er diverse voorstellen zijn om de verschillende aspecten van de software ontwikkeling in formele talen vast te leggen. In de praktijk vinden mensen dat toch erg lastig, en slechts enkele kunnen dat echt. Voor requirements vind men het al te veel moeite om een beetje een verhaaltje te schrijven en komt men liever weg met dingen als enkel "Fout op 3rde pagina inschrijving. Moet anders.", laat staan dat men een dergelijke requirement in een formele (wiskundige) taal gaat omschrijven en de usecases exact gaat modelleren.

Onder het mom van "we moeten agile zijn" en "het moet nu even snel", worden dingen voor nog geen 10% goed gespecificeerd en wordt snel wat in elkaar geflanst. Later mag iemand anders de brokken wel oprapen en de scherven bijeen vegen.

En uit ervaring weet ik dat ICT'ers en communicatie ook inderdaad lang niet altijd hand-in-hand gaan, vrouwelijke ICT'ers laat je horen

Vrouwen zijn inderdaad dikwijls communicatiever dan mannen, maar als je b.v. een hardcore programmeur hebt dan verschillen de mannelijke en de vrouwelijke varianten niet zo veel van elkaar hoor qua communicatie. Je hebt gewoon minder hardcore vrouwelijke programmeurs. Veel vrouwen die in de IT zitten, zitten dan op de wat 'zachtere' functies, dwz functies waar de machine zelf niet het primaire object in de baan is.

[flowerp]

Confusion schreef op zondag 15 juli 2007 @ 10:09:
[...]
Dat is gewoon zelden zo: er is altijd sprake van voortschrijdend inzicht en zeker bij innovatieve projecten kunnen er weleens radicale richtingswijzigingen zijn. Daar moet je vanaf dag 0 rekening mee houden.

Oftewel, het bekende "Anticipation of change". Een van de bekende design qualities die je zo uit een willekeurig boek over software engineering kunt overnemen

Toch is de praktijk wat weerbarstiger. Alles 100% van te voren definiëren gaat niet lukken, maar alles zo flexibel ontwerpen dat je alles kunt vervangen is ook weer niet de bedoeling.

Ik heb best wel een aantal projecten gezien waar men (vroeger) een eigen database abstractie laag ging maken om als het nodig was de DB te kunnen veranderen. Of een eigen GUI abstractie laag om een compleet andere GUI aan de code te kunnen hangen. 9 van de 10 van die projecten hebben echter hun hele leven (=tot wel 10 jaar) gedraaid zonder dat er ook maar eens sprake van is geweest dat dergelijke dingen aangepast moesten worden.

GX schreef op zaterdag 14 juli 2007 @ 13:18:
[...]
Eenieder die de term Agile durft te gebruiken voor zijn aanpak dient ook gewoon te weten wat het precies inhoud. Wat jij beschrijft is "prutsen" en dat heeft bar weinig te maken met welke methode dan ook.

Maar geldt dat niet juist voor deze hele discussie? Weten wat iets betekend en waar je mee bezig bent? Met AJAX is het nu al zo ver dat elk mooi uitziend CSS effect al AJAX wordt genoemd, terwijl er in het geheel geen communicatie met de server plaatsvindt.

Met Agile is het al niet anders. Veel managers en dikwijls zelfs programmeurs hebben een naampje gehoord en roepen maar wat.

Een tijdje geleden zat ik op een project waar iedereen te pas en te onpas riep dat alles KISS moest zijn. De gedachten was echter niet dat je je code simpel hield door zeer elegante refactorings door te voeren (zoals een wiskundige uitdrukking van enkele regels soms vereenvoudigd kan worden tot iets heel kleins maar toch exact hetzelfde zegt). Nee, KISS stond daar gelijk aan het soort code schrijven dat een beginner schrijft die pas een maand bezig is.

Uiteindelijk kwam het dus weer neer op; we willen liever wat prutsen en niet nadenken over dingen als een software architectuur of design patterns. Eigenlijk zijn we gewoon lui en ongeïnteresseerd, maar we hebben een mooi naampje zodat we dit negatieve gedrag positief kunnen laten klinken: KISS!!!

[ Voor 39% gewijzigd door flowerp op 15-07-2007 11:02 ]

[farlane]

AJAX is een workaround om de tekortkomingen van HTTP op te lossen. Het is daar imho niet erg in geslaagd.

[Verwijderd]

ATS schreef op zondag 15 juli 2007 @ 04:27:

... dan spreek je jezelf m.i. tegen. Immers, omdat de X van XML in AJAX zit, gaat AJAX over XML, maar ondanks dat de L van "Language" in XML zit, is XML geen taal. Schiet mij maar lek.

M.i. is de L in XML dus ook een beetje onzin ja, als het aan mij lag had het ook niet zo geheten. Als je een fiets een auto noemt, dan is het nog geen auto. Dat is juist waar het om gaat. Er zijn allerlei dingen die een verkeerde naam hebben. XML is duidelijk geformuleerd aan de hand van HTML, dat zal de reden zijn dat die ML er nog in staat.

Kun je iets zonder semantiek een taal noemen?

Hetzelfde geldt volgens mij ook voor AJAX, kun je iets AJAX noemen als je

1. geen asynchrone (non-blocking) requests doet?
2. geen javascript gebruikt?
3. geen XML document als payload gebruikt?

Bedoelen we dan dus niet eigenlijk "Live Pages", laten we er dan een betere term voor verzinnen.

farlane schreef op zondag 15 juli 2007 @ 12:28:
AJAX is een workaround om de tekortkomingen van HTTP op te lossen. Het is daar imho niet erg in geslaagd.

En die tekortkomingen van HTTP worden opgelost door nog meer dingen net HTTP te gaan doen? Want dat is in principe echt de basis van AJAX, er worden additionele HTTP requests gemaakt om gericht specifieke gegevens op te vragen.

Over welke tekortkomingen van HTTP heb je het dan eigenlijk?

[ Voor 50% gewijzigd door Verwijderd op 15-07-2007 12:42 ]

[Confusion]

Verwijderd schreef op zondag 15 juli 2007 @ 12:32:
Over welke tekortkomingen van HTTP heb je het dan eigenlijk?

Hij heeft het over het gebrek aan state, hoewel ik het er niet mee eens ben dat dat een tekortkoming is. Het HTTP protocol wordt gewoon gebruikt voor dingen waar het nooit voor bedoeld was. Je kan het netzogoed een tekortkoming van auto's noemen dat ze niet kunnen vliegen.

[Verwijderd]

Confusion schreef op zondag 15 juli 2007 @ 12:40:

Hij heeft het over het gebrek aan state, hoewel ik het er niet mee eens ben dat dat een tekortkoming is. Het HTTP protocol wordt gewoon gebruikt voor dingen waar het nooit voor bedoeld was. Je kan het netzogoed een tekortkoming van auto's noemen dat ze niet kunnen vliegen.

Dat bedoel ik dus ook eigenlijk. Hoe kun je het dan een tekortkoming van het HTTP protocol noemen? Het HTTP protocol is overigens ook weer zo'n voorbeeld van een verkeerde naam, maar dat terzijde.

[farlane]

Confusion schreef op zondag 15 juli 2007 @ 12:40:
[...]

Hij heeft het over het gebrek aan state, hoewel ik het er niet mee eens ben dat dat een tekortkoming is. Het HTTP protocol wordt gewoon gebruikt voor dingen waar het nooit voor bedoeld was. Je kan het netzogoed een tekortkoming van auto's noemen dat ze niet kunnen vliegen.

Een auto is geen protocol.

Cheatah schreef op zondag 15 juli 2007 @ 12:44:
[...]

Dat bedoel ik dus ook eigenlijk. Hoe kun je het dan een tekortkoming van het HTTP protocol noemen? Het HTTP protocol is overigens ook weer zo'n voorbeeld van een verkeerde naam, maar dat terzijde.

Als je applicaties wilt bouwen en je hebt daarin een statemachine nodig, in welke vorm dan ook, maar het protocol voorziet daar niet in, dan is dat een tekortkoming. Het kan wel zijn dat er manieren zijn gevonden om daar omheen te werken maar het is en blijft een tekortkoming.

Alleen al het feit dat er sessionvariabelen bedacht zijn is een aanwijzing dat er eigenlijk toch wel een state nodig is voor een niet triviale toepassing.

Btw hoe zou ik volgens jou het HTTP protocol wel moeten noemen dan?

[aex351]

farlane schreef op zondag 15 juli 2007 @ 13:43:
[...]
Btw hoe zou ik volgens jou het HTTP protocol wel moeten noemen dan?

http = http, de p staat overigens voor protocol.

[Creepy]

aex351 schreef op zondag 15 juli 2007 @ 14:26:
[...]

http = http, de p staat overigens voor protocol.

offtopic:
Blijf je mieren&^k&n of ga je ook nog echt wat bijdragen aan deze discussie? Zo nee, reageer dan gewoon niet. Waar die P voor staat weet het gros hier ook wel.

[JKVA]

farlane schreef op zondag 15 juli 2007 @ 13:43:
[...]
Een auto is geen protocol.
[...]

No shit Sherlock. De vergelijking gaat nogthans aardig op.

HTTP is al zo lang geleden gemaakt, met een bepaald doel, dat niet aansluit bij de manier hoe we het nu gebruiken. HTTP is ouder dan AJAX (en niet alleen de naam AJAX, ook het concept) dus wat mij betreft is het geen tekortkoming, het is een fact of life.

[...]
Als je applicaties wilt bouwen en je hebt daarin een statemachine nodig, in welke vorm dan ook, maar het protocol voorziet daar niet in, dan is dat een tekortkoming. Het kan wel zijn dat er manieren zijn gevonden om daar omheen te werken maar het is en blijft een tekortkoming.

Alleen al het feit dat er sessionvariabelen bedacht zijn is een aanwijzing dat er eigenlijk toch wel een state nodig is voor een niet triviale toepassing.

Ik wens je veel succes met een alternatief. Al jaren lopen mensen HTTP af te zeiken zonder argumenten/tegenvoorstellen. Hoe zou jij een google suggest aanpakken? Voor elke gebruiker in de wereld een connectie openhouden?

HTTP is stateless en dat is goed. Op de server staan dingen en daar hoef jij als client helemaal niet bij te kunnen. Dat is het idee van client-server, dat de server werk verricht en resultaten daarvan naar de client stuurt.

Noem maar eens een werkbaar alternatief voor het stateless http. Tenslotte zit je het af te zeiken, dus ik neem aan dat je stateful http nodig hebt ergens voor. Geef daar maar eens een voorbeeld van.

Btw hoe zou ik volgens jou het HTTP protocol wel moeten noemen dan?

Wat mij betreft is HTML een prima naam. Het dient voor de overdracht van Hypertext berichten. En wat is (X)HTML? Juist ja, een hypertext bestand. Dat hypertext tegenwoordig niet meer cool klinkt, ok, maar de naam is nog zeer kloppend.

[farlane]

JKVA schreef op zondag 15 juli 2007 @ 14:59:
No shit Sherlock. De vergelijking gaat nogthans aardig op.

Niet zoals daar staat vermeld, als ik wil gaan vliegen pak ik iets dat kan vliegen en geen auto.

HTTP is al zo lang geleden gemaakt, met een bepaald doel, dat niet aansluit bij de manier hoe we het nu gebruiken. HTTP is ouder dan AJAX (en niet alleen de naam AJAX, ook het concept) dus wat mij betreft is het geen tekortkoming, het is een fact of life.

Dat het een fact of life is sluit niet uit dat het een tekortkoming is.

.... rant ...

Het feit dat ik geen betere oplossing weet neemt mijn recht om kritiek te uiten niet weg.

Wat mij betreft is HTML een prima naam. Het dient voor de overdracht van Hypertext berichten.

De opmerking ging over:

Het HTTP protocol is overigens ook weer zo'n voorbeeld van een verkeerde naam, maar dat terzijde

Mij vraag aan Cheatah was eigenlijk of ik het in een verkeerde context gebruik of dat hij de naam zelf verkeerd vindt.
Ik ga er even vanuit dat waar jij HTML neerzet dat je eigenlijk HTTP bedoelt anders slaat het nl nergens op.

[aex351]

Creepy schreef op zondag 15 juli 2007 @ 14:43:
[...]

offtopic:
Blijf je mieren&^k&n of ga je ook nog echt wat bijdragen aan deze discussie? Zo nee, reageer dan gewoon niet. Waar die P voor staat weet het gros hier ook wel.

En jij bepaald zo even 123 dat iedereen dat wel weet. De persoon op wie ik reageer trekt de betekenis in twijfel en ik leg hem uit dat http betekend wat de afkorting voor staat, waarbij ik alleen expliciet de p noem vanwege de context waarop ik reageer.

[ Voor 18% gewijzigd door Creepy op 15-07-2007 22:51 ]

[farlane]

aex351 schreef op zondag 15 juli 2007 @ 15:49:
En jij bepaald zo even 123 dat iedereen dat wel weet. De persoon op wie ik reageer trekt de betekenis in twijfel en ik leg hem uit dat http betekend wat de afkorting voor staat, waarbij ik alleen expliciet de p noem vanwege de context waarop ik reageer.

Erm nee je legt helemaal niets uit, het enige dat je zegt is 'http = http'. Dat draagt zoals Creepy al aangaf vrij weinig bij aan de discussie

[aex351]

farlane schreef op zondag 15 juli 2007 @ 16:20:
[...]
Erm nee je legt helemaal niets uit, het enige dat je zegt is 'http = http'. Dat draagt zoals Creepy al aangaf vrij weinig bij aan de discussie

Kijk, het volgende vertel jij

[...]
Btw hoe zou ik volgens jou het HTTP protocol wel moeten noemen dan?

Ik vat dit op als jij die niet weet waar http voor staat. Immers je verteld dat je niet weet hoe http anders genoemd zou moeten worden. Dit terwijl http opzichzelf staand al een vaste betekenis heeft en de vraag hoe http anders genoemd zou moeten worden helemaal niet relevant is. Om dit nog meer te onderbouwen. Het woord protocol zet je naast http neer terwijl http al in de afkorting het woord protocol bevat. Dit zou je kunnen zien als de afkorting ipv (in plaats van) als volgt neer te zetten. Hè piet waarom gebruik jij Y niet IPV van X. Zoals je ziet klopt dit niet.

Duidelijk zo?

[.oisyn]

Wat een geblaat. HTTP is de naam van het protocol, en dus spreek je van "HTTP" of "het HTTP protocol". Dat protocol al in de afkorting staat doet er niet toe. Net als bij woorden als PIN-code. Argeer je ook tegen iedereen die dat "fout" zegt?

Ik denk dat de reden om HTTP niet HTTP genoemd kan worden is omdat er niet per se hypertext getransferred wordt. Maar zoals bij zoveel afkortingen heeft de afkorting zelf een andere intrensieke betekenis gekregen en betekent het niet meer letterlijk HyperText Transfer Protocol.

Kabel mag ook geen DSL heten, edoch het toch echt een Digital Subscriber Line is. DSL gaat om de achterliggende techniek, en betekent dus veel meer dan alleen z'n afkorting. AJAX en HTTP zijn niet veel anders.

flowerp schreef op zondag 15 juli 2007 @ 10:30:
Feitelijk is XML dus alleen een syntax, een soort meta taal.

Meta-taal lijkt me niet de correcte term, het is namelijk geen taal die een taal beschrijft . XML is gewoon een structuur, niets meer en niets minder. Die structuur kun je vervolgens gebruiken om een taal op te layeren, of een dataformaat, of een meta-formaat die een ander formaat beschrijft (zoals DTD), maar dat zijn in principe allemaal subsets van de totale XML ruimte.

[ Voor 42% gewijzigd door .oisyn op 15-07-2007 17:45 ]

[Ashtaroth]

.oisyn schreef op zondag 15 juli 2007 @ 17:39:
...XML is gewoon een structuur, niets meer en niets minder. Die structuur kun je vervolgens gebruiken om een taal op te layeren...

XML is geen structuur, maar een taal waarmee je de structuur van data beschrijft. En wat bedoel je met het oplayeren (?!) van een taal? Hier snap ik echt niets van.

[.oisyn]

Ashtaroth schreef op zondag 15 juli 2007 @ 21:19:
XML is geen structuur, maar een taal waarmee je de structuur van data beschrijft.

Nee, je beschrijft de data zelf, niet de structuur van die data. En die data kan zelf ook weer een beschrijving van de structuur van data zijn, zoals bijvoorbeeld een DTD schema.

Ik vond "taal" een onjuiste term, maar ik zie dat dictionary.com's definitie van language wat algemener is dan vandale's definitie van taal, dus in dat opzicht kun je het wel een taal noemen.

Desalniettemin, het blijft een structuur om data mee op te slaan.

En wat bedoel je met het oplayeren (?!) van een taal? Hier snap ik echt niets van.

Ik bedoel dat je de syntax van xml gebruikt als basis van de syntax van je programmeertaal. Die programmeertaal is dan XML, maar wel een subset van XML, dus XML is niet per se een programmeertaal (een auto is een voertuig, maar een voertuig is niet per definite een auto).

[ Voor 19% gewijzigd door .oisyn op 15-07-2007 21:28 ]

[farlane]

aex351 schreef op zondag 15 juli 2007 @ 17:10:
... *ugh* ...

Het feit dat ik kritiek uit op Ajax/HTTP wil eigenlijk al zeggen dat ikzelf vind dat ik er genoeg vanaf weet om er kritiek op te mogen uiten ( vertellen waar HTTP de afkorting van is lijkt me niet nodig btw ).
Voor de rest slaat je verhaal helemaal nergens op en ik krijg het gevoel dat je met zoveel mogelijk woorden zo min mogelijk zinnigs wilt zeggen.

.oisyn schreef op zondag 15 juli 2007 @ 17:39:
Ik denk dat de reden om HTTP niet HTTP genoemd kan worden is omdat er niet per se hypertext getransferred wordt. Maar zoals bij zoveel afkortingen heeft de afkorting zelf een andere intrensieke betekenis gekregen en betekent het niet meer letterlijk HyperText Transfer Protocol.

Ah ok op die manier.

Is dit misschien dan ook zo'n voorbeeld van een techniek ( in dit geval een protocol ) waar veel te lang aan vastgehouden is alleen om backwards compatible te blijven en waar we nu met zijn allen omheen proberen te werken met technieken als AJAX?

[aex351]

farlane schreef op zondag 15 juli 2007 @ 21:49:
[...]
Het feit dat ik kritiek uit op Ajax/HTTP wil eigenlijk al zeggen dat ikzelf vind dat ik er genoeg vanaf weet om er kritiek op te mogen uiten ( vertellen waar HTTP de afkorting van is lijkt me niet nodig btw ).
Voor de rest slaat je verhaal helemaal nergens op en ik krijg het gevoel dat je met zoveel mogelijk woorden zo min mogelijk zinnigs wilt zeggen.

Ik sta open voor kritiek maar dan moet je jouw mening wel met goede geldige argumenten onderbouwen.

.oisyn schreef op zondag 15 juli 2007 @ 17:39:
Wat een geblaat. HTTP is de naam van het protocol, en dus spreek je van "HTTP" of "het HTTP protocol". Dat protocol al in de afkorting staat doet er niet toe. Net als bij woorden als PIN-code. Argeer je ook tegen iedereen die dat "fout" zegt?

Lees mijn reply nogmaals. Het gaat er niet om dat sommige mensen "http protocol" zeggen. Dus expliciet het woord protocol erachter aan maar het feit dat ik van mening was dat de persoon op wie ik reageerde uberhaubt niet wist wat http nou precies inhoud. Dat doe ik trouwens bij iedereen die aangeeft dat http geen correcte naam is voor http. Dat is vertellen als de letter A geen goede benaming is voor de letter A. Dan ga je toch ook twijfelen als die persoon de alfabet wel goed kent, althans ik wel.

[ Voor 42% gewijzigd door aex351 op 15-07-2007 22:18 ]

[Confusion]

farlane schreef op zondag 15 juli 2007 @ 15:25:
Niet zoals daar staat vermeld, als ik wil gaan vliegen pak ik iets dat kan vliegen en geen auto.

Dat is juist het punt . Als je stateful een verbinding op wilt zetten, pak je idealiter een protocol dat daar voor dient. HTTP is er duidelijk niet voor bedoeld en het een gebrek van HTTP noemen dat het geen stateful verbindingen ondersteunt, is dus hetzelfde als het een gebrek van auto's noemen dat ze niet kunnen vliegen. Als je wilt vliegen, moet je een vliegtuig pakken. Het effectief stateful maken van HTTP is overigens makkelijker dan het laten vliegen van auto's, hoewel ook het laatste best mogelijk is.

offtopic:
Wat betreft de vorm van je argument: tegen een analogie tussen A en B kan je niet inbrengen 'een A is geen B, dus de analogie deugt niet'. Er zijn oneindig veel analogieen waarmee wij elkaar dingen duidelijk kunnen maken, terwijl je datzelfde argument tegen al die analogieen in zou kunnen brengen. Het is dus geen geldig argument. Als je de analogie niet deugdelijk vind, moet je uitleggen waarom het doel van de analogie door B niet geillustreerd wordt.

[.oisyn]

aex351 schreef op zondag 15 juli 2007 @ 22:14:
Lees mijn reply nogmaals.

Wellicht begint het je al te dagen dat het niet handig is een onduidelijke one-liner neer te plempen, gezien de aard van de reacties die je erop krijgt.

[Creepy]

aex351 schreef op zondag 15 juli 2007 @ 17:10:
[...]

Ik vat dit op als jij die niet weet waar http voor staat. Immers je verteld dat je niet weet hoe http anders genoemd zou moeten worden. Dit terwijl http opzichzelf staand al een vaste betekenis heeft en de vraag hoe http anders genoemd zou moeten worden helemaal niet relevant is. Om dit nog meer te onderbouwen. Het woord protocol zet je naast http neer terwijl http al in de afkorting het woord protocol bevat. Dit zou je kunnen zien als de afkorting ipv (in plaats van) als volgt neer te zetten. Hè piet waarom gebruik jij Y niet IPV van X. Zoals je ziet klopt dit niet.

Duidelijk zo?

Leg dan meteen uit wat je echt bedoelt i.p.v. een totaal niets zeggende oneliner. Het naampje is inderdaad totaal niet relevant.

offtopic:
En dit is de laatste offtopic hier: voor kritiek op moderatie hebben we een speciaal topic. Doe dat dan ook daar of DM mij!

En nog meteen een move naar SEA ook

[flowerp]

Confusion schreef op zondag 15 juli 2007 @ 22:19:
[...]Als je stateful een verbinding op wilt zetten, pak je idealiter een protocol dat daar voor dient. HTTP is er duidelijk niet voor bedoeld

Inderdaad, HTTP is er overduidelijk niet voor bedoeld. Maar omdat mensen het toch eisen moeten wij als programmeurs en designers ons in allerlei belachelijke bochten wringen om het toch mogelijk te maken.

Ik heb jaren lang applicaties voor de desktop gemaakt. Veel dingen zijn daar voor de programmeur zoveel makkelijker. Antieke toolkits als MFC boden jaren geleden al een volledig MVC en MDI model, zonder te veel gedoe. Rich controls waren bijna triviaal. Een progressbar ergens aan hangen was even simpel als een knop op het scherm tonen. Etc.

Toen ik zo rond 2002 de overstap naar web applicaties maakte wist ik eerst niet wat me overkwam. Het leek wel of ik >10 jaar terug in de tijd terecht kwam qua software opzet. Met moderne frameworks als JSF en ASP.NET icm inderdaad AJAX en voor Java omgevingen SEAM begint het eindelijk weer een beetje ergens op te lijken, maar nog steeds is het een schrale programmeer omgeving en een enorm eigenlijk onnodig gedoe.

Iedereen blaat wel dat programmeren makkelijker moet worden, omdat mankracht tegenwoordig veel kostbaarder is dan machinekracht, maar door het HTTP protocol te gebruiken voor iets waar het nimmer voor bedoeld was halen we ons onnodig veel werk op de hals.

Al dat gedoe met pagescope, request scope, session scope, en het omslachtig emuleren van een conversation scope (voor state tussen pagina's). Om maar te zwijgen over alle lijm code om request parameters te decoderen uit strings naar types, en dat telkens heen en weer te gooien tussen client en server. En om dan maar helemaal te zwijgen over problemen met back-button, refreshes, en bookmarks.

Jaren lang heeft iedereen dit telkens weer opnieuw moeten oplossen door eigen mini-frameworkjes te layeren over HTTP/HTML. De verloren man uren die dit gekost heeft zal werkelijk in de miljoenen lopen. Nu komen er dus wel langzaam frameworks die het geheel voor de programmeur de illusie van statefullness geven, maar ook deze frameworks zijn nog niet perfect. Het zullen dus nog wel enkele miljoenen totaal verspilde man uren worden voordat HTTP zo ingekapseld is dat het werkelijk statefull zonder gotcha's te gebruiken is.

[crisp]

flowerp schreef op zondag 15 juli 2007 @ 23:48:
[...]


Inderdaad, HTTP is er overduidelijk niet voor bedoeld. Maar omdat mensen het toch eisen moeten wij als programmeurs en designers ons in allerlei belachelijke bochten wringen om het toch mogelijk te maken.

Och, sommigen zien het als 'je in allerlei belachelijke bochten moeten wringen', anderen zien het juist als een uitdaging

Ik heb jaren lang applicaties voor de desktop gemaakt. Veel dingen zijn daar voor de programmeur zoveel makkelijker. Antieke toolkits als MFC boden jaren geleden al een volledig MVC en MDI model, zonder te veel gedoe. Rich controls waren bijna triviaal. Een progressbar ergens aan hangen was even simpel als een knop op het scherm tonen. Etc.

Met andere woorden: je bent gewoon verwent geraakt

Toen ik zo rond 2002 de overstap naar web applicaties maakte wist ik eerst niet wat me overkwam. Het leek wel of ik >10 jaar terug in de tijd terecht kwam qua software opzet. Met moderne frameworks als JSF en ASP.NET icm inderdaad AJAX en voor Java omgevingen SEAM begint het eindelijk weer een beetje ergens op te lijken, maar nog steeds is het een schrale programmeer omgeving en een enorm eigenlijk onnodig gedoe.

Desktop programming bestaat ook al wat langer dan webprogramming, het is dus niet vreemd dat het laatste wat achterloopt op het eerste.

Iedereen blaat wel dat programmeren makkelijker moet worden, omdat mankracht tegenwoordig veel kostbaarder is dan machinekracht, maar door het HTTP protocol te gebruiken voor iets waar het nimmer voor bedoeld was halen we ons onnodig veel werk op de hals.

Maar ik heb ook nog geen viable alternatieve suggesties gezien...

Al dat gedoe met pagescope, request scope, session scope, en het omslachtig emuleren van een conversation scope (voor state tussen pagina's). Om maar te zwijgen over alle lijm code om request parameters te decoderen uit strings naar types, en dat telkens heen en weer te gooien tussen client en server. En om dan maar helemaal te zwijgen over problemen met back-button, refreshes, en bookmarks.

Tsja, in feite is een webapplicatie ook niet te vergelijken met een desktop applicatie. Ten eerste praat je al over een heterogene omgeving (verschillende browsers) tov een redelijk homogene omgeving voor desktop applicaties, en ten tweede over een veel breder publiek met heel andere verwachtingen over hoe een applicatie zich in een browser dient te gedragen.

Jaren lang heeft iedereen dit telkens weer opnieuw moeten oplossen door eigen mini-frameworkjes te layeren over HTTP/HTML. De verloren man uren die dit gekost heeft zal werkelijk in de miljoenen lopen. Nu komen er dus wel langzaam frameworks die het geheel voor de programmeur de illusie van statefullness geven, maar ook deze frameworks zijn nog niet perfect. Het zullen dus nog wel enkele miljoenen totaal verspilde man uren worden voordat HTTP zo ingekapseld is dat het werkelijk statefull zonder gotcha's te gebruiken is.

Ik vraag me af of dat allemaal wel de schuld van het onderliggende protocol is, ik denk maar ten dele namelijk. En hoeveel manuur zijn er wel niet 'verspilt' voordat frameworks en IDE's voor desktop-applicaties op het huidige niveau zijn gekomen?

Ergens mee bezig zijn geeft ook inzicht in de problemen en daarmee mogelijk een aanwijzing voor een beter alternatief. Blijkbaar zijn we nog niet zo ver, en daarmee zou ik de huidige tijd die wordt gestoken in de ontwikkeling van frameworks voor webapplicaties zeker niet als verspilt beschouwen...

[djc]

flowerp schreef op zondag 15 juli 2007 @ 23:48:
Inderdaad, HTTP is er overduidelijk niet voor bedoeld. Maar omdat mensen het toch eisen moeten wij als programmeurs en designers ons in allerlei belachelijke bochten wringen om het toch mogelijk te maken.

Ach, noem je cookies nou "allerlei belachelijke bochten"?

[flowerp]

crisp schreef op maandag 16 juli 2007 @ 00:09:
[...]
Och, sommigen zien het als 'je in allerlei belachelijke bochten moeten wringen', anderen zien het juist als een uitdaging

Tsja, das ook wel weer waar

Hoewel de echte uitdagingen natuurlijk de begintijd was van b.v. de C64; in slechts 64KB en met een ~1Mhz een applicatie bouwen die nog flink wat nuttigs deed ook. Cycles tellen in assembly was aan de orde van dag en instructies of data moest je zo schrijven dat je ze dubbel kon gebruiken door tussen de opcoded te springen.

Met andere woorden: je bent gewoon verwent geraakt

Misschien wel, maar hoewel ik nog steeds met plezier programmeer moet er nu ook brood op de plank komen en klanten tevreden gehouden worden. Vroeger kon ik veel meer tijd stoppen in uitdagingen. Tegenwoordig moet het toch wat pragmatischer.

Maar ik heb ook nog geen viable alternatieve suggesties gezien...

Qua programmeer model heb je natuurlijk het X Window systeem. Kun je compleet remote een rich en statefull application draaien. Helaas is de implementatie niet echt (of eigenlijk echt niet) geschikt om over het internet gebruikt te kunnen worden.

Maar ik denk dat het idee in een implementatie die speciaal voor het Internet ontwikkeld was, wel zeker een goede kans van slagen had gehad. X zelf bestaat ook nu al voor zeer veel systemen, in diverse implementaties. X applicaties werken echter overal, tussen elke client en server.

De reden dat X niet werkt over het Internet is oa dat het veels te veel bandbreedte vraagt en lage latencies vereist. Voor dingen als het scrollen van een document wordt voor elke pixel contact met de server opgenomen, en vliegen er veels te veel events heen en weer. Het werkt echter wel volledig transparant voor de programmeur.

Een andere extreem is een Java app die via java web start gelanceerd wordt, geheel lokaal draait en alleen voor data contact opneemt met de server.

Wellicht dat voor remote applications een combinatie tussen deze 2 uitersten een oplossing biedt; een X11 achtig protocol, maar met de mogelijkheid om intelligent widgets door de client uit te laten voeren. Deze widgets kunnen dan geprogrammeerd worden op exact dezelfde manier waarop nu ook al native widgets gemaakt worden; dezelfde widget zou dan ook gewoon zowel in een desktop applicatie als in web applicatie gebruikt kunnen worden.

Ik vraag me af of dat allemaal wel de schuld van het onderliggende protocol is, ik denk maar ten dele namelijk.

Soms zijn het misschien ook maar kleine dingetjes die voor web applicaties al een boel verlichting zouden kunnen brengen. Een echt window-id, en een intelligentere omgang met de back-button en refreshes zouden al een boel van de pijn kunnen verzachten waar we momenteel aan de serverside mee zitten. HTTP 1.1 is van 1999 ofzo? Het zou wel eens tijd mogen worden voor een update die wat beter aansluit bij het huidige gebruik ervan.

En hoeveel manuur zijn er wel niet 'verspilt' voordat frameworks en IDE's voor desktop-applicaties op het huidige niveau zijn gekomen?

Das natuurlijk ook waar.

[flowerp]

Manuzhai schreef op maandag 16 juli 2007 @ 00:28:
[...]
Ach, noem je cookies nou "allerlei belachelijke bochten"?

Een cookie is wel een erg grove vorm van state...

[crisp]

flowerp schreef op maandag 16 juli 2007 @ 01:20:
[...]
Een andere extreem is een Java app die via java web start gelanceerd wordt, geheel lokaal draait en alleen voor data contact opneemt met de server.

En hoe is dat anders dan een AJAX-applicatie?

[flowerp]

crisp schreef op maandag 16 juli 2007 @ 01:53:
[...]
En hoe is dat anders dan een AJAX-applicatie?

Het principe dat je vanaf de server een applicatie naar de client download en direct opstart is een overeenkomst.

De verschillen zitten hem erin dat Java een taal en platform is die veel meer support heeft om echte applicaties te bouwen. Het platform zelf is natuurlijk een zeer grote factor sneller (zie b.v. http://shootout.alioth.de...ang=java&lang2=javascript), heeft een volwassen OO implementatie, kent packages, en niet onbelangrijk in deze context, heeft ook een zeer volwassen netwerk stack.

Ik weet van je andere posts dat jij een grote fan bent van javascript en ik weet dat er meer mee kan dan menig persoon denkt, maar voor echte applicatie development moet je natuurlijk wel toegeven dat platformen als Java, maar ook C#/.NET natuurlijk een hele hoop bieden wat (nog) niet met javascript kan.

Ik heb een aantal 'echte' applicaties gezien die in Javascript gebouwd waren, maar voor applicaties van het niveau van b.v. Eclipse of Paint.net zie ik Javascript nog niet echt gebruikt worden.

[JKVA]

flowerp schreef op maandag 16 juli 2007 @ 02:38:
[...]


Het principe dat je vanaf de server een applicatie naar de client download en direct opstart is een overeenkomst.

De verschillen zitten hem erin dat Java een taal en platform is die veel meer support heeft om echte applicaties te bouwen. Het platform zelf is natuurlijk een zeer grote factor sneller (zie b.v. http://shootout.alioth.de...ang=java&lang2=javascript), heeft een volwassen OO implementatie, kent packages, en niet onbelangrijk in deze context, heeft ook een zeer volwassen netwerk stack.

Ik weet van je andere posts dat jij een grote fan bent van javascript en ik weet dat er meer mee kan dan menig persoon denkt, maar voor echte applicatie development moet je natuurlijk wel toegeven dat platformen als Java, maar ook C#/.NET natuurlijk een hele hoop bieden wat (nog) niet met javascript kan.

Ik heb een aantal 'echte' applicaties gezien die in Javascript gebouwd waren, maar voor applicaties van het niveau van b.v. Eclipse of Paint.net zie ik Javascript nog niet echt gebruikt worden.

Ik denk idd ook dat de verschillen tussen JS/AJAX en Web Start/'Remoting API' vooral betrekking hebben op volwassenheid van de taal. Stateful-/-lessheid heeft daar op zich niets mee te maken. Je hebt gewoon een model dat niet in-process bijgehouden wordt, waardoor het duurder is om beschikbaar te stellen aan clients.
Bovendien is AJAX push nog niet echt volwassen te noemen, waardoor de server geen (MVC) notify naar views kan sturen. Indien je dat dan toch wilt, moet je gaan customizen met comet of piggybacken ofzo. Tegelijk moet je rekening houden met netwerkverkeer.

Maar deze zaken heb je ook bij client applicaties die op de ene of andere manier met een centrale server communiceren (syncen met DB ofzo). Daar speelt hetzelfde, behalve dat ze misschien op de client state bewaren en in batch syncen. Dat is dus ook een omweg...

[djc]

flowerp schreef op maandag 16 juli 2007 @ 01:21:
Een cookie is wel een erg grove vorm van state...

Zodra je cookies hebt is het vrij straightforward om daar bovenop state te programmeren zoals jij dat prettig vindt.

[Hydra]

Confusion schreef op zondag 15 juli 2007 @ 10:09:
Jawel, de methode: leer je developers dat dat zo zal zijn en leer ze defensief genoeg te programmeren, zodat die nieuwe requirements snel in het systeem te hangen zijn. Dat er zoiets als 'mismanagement van requirements' kan zijn, gaat uit van het idee dat je vantevoren je requirements vast kan stellen.

Euh, ik weet niet wat voor'n soort projecten jij meestal aan werkt, maar meestal staat vooraf redelijk vast wat een klant wil. Een frontoffice systeem met functionaliteit A, B en C uit uit oude systeem, nieuwe functionaliteit X, Y en Z en een koppeling met de customer-facing website. Tadaa, je hebt een begin. Dan specificieer je de functionaliteiten een stuk verder uit en je weet in een vrij groot detail WAT je gaat doen. Nog niet precies hoe, maar wel wat. Wat je gaat doen leg je vast in een document, een klant gaat accoord, en je begint te bouwen. Of je nu voor een tradiotioneel watervalmodel of iets als RUP gaat, je bedenkt vooraf wat je gaat maken. Tuurlijk zullen er voortschreidende inzichten voorbij komen, maar als dat een 180 graden draai tenopzichte van de vorige koers is, is er sprake van mismanagement.

Ik vind het treffend dat zo veel mensen dat eeuwenoude idee van "de klant weet toch niet wat 'ie wil dus we bouwen het wel voor 'em" aanhangt. Ik vind dat nergens op slaan. De klant weet prima WAT 'ie wil, hij weet alleen niet HOE het het beste geimplementeerd kan worden. Daar ben je nou software engineer voor.

Manuzhai schreef op maandag 16 juli 2007 @ 11:02:
[...]
Zodra je cookies hebt is het vrij straightforward om daar bovenop state te programmeren zoals jij dat prettig vindt.

Ik snap het probleem ook niet. Het protocol is stateless, maar de applicatieserver die daarachter hangt absoluut niet. Daar heb je sessies voor. Ajax is mijns inziens ook helemaal niet bedoeld om HTTP/webapplicaties meer 'stateful' te maken, maar meer om een applicatie look 'n feel te geven waarbij je de voordelen van thick-clients (geen zichtbare round-trips, rich-media, etc.) combineert met de voordelen van webapplicaties (min of meer platformonafhankelijk, geen speciale installatie requirements, etc.).

[.oisyn]

Manuzhai schreef op maandag 16 juli 2007 @ 11:02:
[...]
Zodra je cookies hebt is het vrij straightforward om daar bovenop state te programmeren zoals jij dat prettig vindt.

Zoals ik het prettig vind, is er een statemachine waarbij je vanuit een bepaalde state niet naar een willekeurige andere state kunt. Helaas hebben browsers zoiets als een cache, navigatieknoppen en een refresh knop, die de boel nogal in de war kunnen schoppen. Dat maakt het allemaal wat onvoorspelbaar, hence de rare bochten waarin je je moet wringen om dat solide op te zetten. Zeker niet onmogelijk, maar het had makkelijker geweest als je gewoon een stateful protocol had .

[JKVA]

Hydra schreef op maandag 16 juli 2007 @ 13:53:
[...]


Euh, ik weet niet wat voor'n soort projecten jij meestal aan werkt, maar meestal staat vooraf redelijk vast wat een klant wil. Een frontoffice systeem met functionaliteit A, B en C uit uit oude systeem, nieuwe functionaliteit X, Y en Z en een koppeling met de customer-facing website. Tadaa, je hebt een begin. Dan specificieer je de functionaliteiten een stuk verder uit en je weet in een vrij groot detail WAT je gaat doen. Nog niet precies hoe, maar wel wat. Wat je gaat doen leg je vast in een document, een klant gaat accoord, en je begint te bouwen. Of je nu voor een tradiotioneel watervalmodel of iets als RUP gaat, je bedenkt vooraf wat je gaat maken. Tuurlijk zullen er voortschreidende inzichten voorbij komen, maar als dat een 180 graden draai tenopzichte van de vorige koers is, is er sprake van mismanagement.

Ik vind het treffend dat zo veel mensen dat eeuwenoude idee van "de klant weet toch niet wat 'ie wil dus we bouwen het wel voor 'em" aanhangt. Ik vind dat nergens op slaan. De klant weet prima WAT 'ie wil, hij weet alleen niet HOE het het beste geimplementeerd kan worden. Daar ben je nou software engineer voor.


[...]


Ik snap het probleem ook niet. Het protocol is stateless, maar de applicatieserver die daarachter hangt absoluut niet. Daar heb je sessies voor. Ajax is mijns inziens ook helemaal niet bedoeld om HTTP/webapplicaties meer 'stateful' te maken, maar meer om een applicatie look 'n feel te geven waarbij je de voordelen van thick-clients (geen zichtbare round-trips, rich-media, etc.) combineert met de voordelen van webapplicaties (min of meer platformonafhankelijk, geen speciale installatie requirements, etc.).

Idd, ik snap ook niet waarom mensen brullen dat http stateful moet zijn. ik heb nog geen enkel argument gehoord, alleen maar dat het heel erg nodig is en dat AJAX eigenlijk een hack is om stateful http te krijgen.

Hoe kan een transport protocol nou state hebben? Een vrachtwagen heeft ook state, maar alleen zolang deze op de weg rijdt, daarna is alle state foetsie.
Zo hoort het volgens mij ook. In een client applicatie hebben de communicatielijnen tussen het model (+ eventueel controller) enerzijds en de views (+ eventueel controller) anderzijds ook geen state. Ze dienen enkel voor transport van events, commando's en data.

In een webapplicatie is de server in feite het model + controller. De client browser incl pagina is de view. HTTP is het lijntje ertussen dat data overstuurt. Bij AJAX kan de client eventueel ook nog een controller functie vervullen.

@.oisyn:
Je server side logica dient bepaalde state overgangen af te vangen en ja, dit is soms lastig (vandaar dat er ondertussen een hele zwik frameworks voor te krijgen is, waarmee je alleen ff je state diagram middels XML vastlegt en het framework alles regelt).

Wat bedoel je met stateful protocol? Dat je geen back button hebt? Of dat het HTTP protocol voor jouw specifieke logica bepaalt of een back actie toegestaan is? Volgens mij is dat geen taak voor een dataoverdracht protocol, maar voor applicatielogica.

[Hydra]

.oisyn schreef op maandag 16 juli 2007 @ 14:54:
Zoals ik het prettig vind, is er een statemachine waarbij je vanuit een bepaalde state niet naar een willekeurige andere state kunt. Helaas hebben browsers zoiets als een cache, navigatieknoppen en een refresh knop, die de boel nogal in de war kunnen schoppen.

Valt erg mee. Je kunt prima bijvoorbeeld aangeven dat een pagina niet gecached kan worden, of je kunt relevante state informatie in je pagina (d.m.v. hidden fields bijvoorbeeld; asp.net 1.0 doet dat, op een nogal bloated manier, zelfs helemaal automatisch voor je). HTTP is niets meer dan een transportprotocol. Ik neem aan dat die 3D games waar jullie mee werken via UDP bijvoorbeeld werken? Dat is ook een volledig stateless protocol.

De meeste frontoffice applicaties zijn voornamelijk form-based, en die zijn over het algemeen prima in webapplicaties te vangen. Daarnaast zijn customer-facing webapplicaties natuurlijk ook een hot-business, en een gelikte site verkoopt gewoon. AJAX ondersteunt usability, alleen al zonder zichtbare roundtrip een pagina updaten geeft een veel betere feel aan websites, en klanten willen graag dat hun site 'bigger, better and faster' is dan die van hun concurrent.

[.oisyn]

Nu ik erover nadenk is het niet eens zozeer het HTTP protocol zelf, maar meer het fenomeen "webbrowsing". Als je niet wilt dat users dmv bookmarks e.d. naar het midden van een een of ander proces springen, zou je er natuurlijk ook voor kunnen zorgen dat dat gedeelte gewoon geen aparte pagina is. En wat back/forward knoppen betreft, eigenlijk zou je die weer willen kunnen afvangen zodat je daar in de context van je webapp een zinnige betekenis aan kunt geven.

Je blijft echter wel zitten met het feit dat je geen info vanaf de server kunt pushen naar de client; die zal moeten pollen. En dat is wél een tekort van HTTP voor dit soort doeleinden.

Hydra schreef op maandag 16 juli 2007 @ 15:45:
Ik neem aan dat die 3D games waar jullie mee werken via UDP bijvoorbeeld werken? Dat is ook een volledig stateless protocol.

ik denk niet alleen maar in termen van games hoor

[Confusion]

Hydra schreef op maandag 16 juli 2007 @ 13:53:
Euh, ik weet niet wat voor'n soort projecten jij meestal aan werkt, maar meestal staat vooraf redelijk vast wat een klant wil. Een frontoffice systeem met functionaliteit A, B en C uit uit oude systeem, nieuwe functionaliteit X, Y en Z en een koppeling met de customer-facing website.

En halverwege bedenken ze dat ze ook functionaliteit AA er bij willen, een koppeling met Foo en dat eigenlijk de database aan redesign toe is.

Ik vind het treffend dat zo veel mensen dat eeuwenoude idee van "de klant weet toch niet wat 'ie wil dus we bouwen het wel voor 'em" aanhangt. Ik vind dat nergens op slaan.

Strooien mannen slaan ook nergens op.

De klant weet prima WAT 'ie wil, hij weet alleen niet HOE het het beste geimplementeerd kan worden. Daar ben je nou software engineer voor.

Bij onze klanten zijn er nog geen legers business process consultants en dergelijke langsgeweest. Die moet je helpen helder te krijgen wat ze willen. Daarbij ontdekken ze mogelijkheden en een maand later weten ze opeens dat ze 1 van die mogelijkheden willen realiseren. Gelukkig hebben wij daar dan rekening mee gehouden.

[Hydra]

.oisyn schreef op maandag 16 juli 2007 @ 16:05:
Nu ik erover nadenk is het niet eens zozeer het HTTP protocol zelf, maar meer het fenomeen "webbrowsing". Als je niet wilt dat users dmv bookmarks e.d. naar het midden van een een of ander proces springen, zou je er natuurlijk ook voor kunnen zorgen dat dat gedeelte gewoon geen aparte pagina is. En wat back/forward knoppen betreft, eigenlijk zou je die weer willen kunnen afvangen zodat je daar in de context van je webapp een zinnige betekenis aan kunt geven.

Het is echt helemaal niet moeilijk af te vangen. Als je ziet dat een gebruiker deeplinked zonder eerst op de frontpage langs te zijn geweest (via een crumb-trail ofzo), redirect je 'em gewoon terug naar start. Je applicatie weet wel of een state geldig is of niet. Je applicatie draait op de server, wat er in de browser gebeurt is slechts de view.

Je blijft echter wel zitten met het feit dat je geen info vanaf de server kunt pushen naar de client; die zal moeten pollen. En dat is wél een tekort van HTTP voor dit soort doeleinden.

Definieer 'dit soort doeleinden' alsjeblieft? Want dingen als 3D-games zul je niet snel binnen een browser game gaan vatten misschien, maar de meeste workflow processen enzo zijn voornamelijk formulier-based. nu was sleur-en-pleur iets wat je tot voor 'kort' niet makkelijk in een webapplicatie kunt doen, maar "Web 2.0" technieken als Ajax zorgen ervoor dat webapplicaties de mogelijkheden van thick clients krijgen. Er is erg weinig wat betreft enterprise/workflow dat niet in een webapp te vangen is.

Wat betreft dat niet kunnen pushen: tja, ik zie dat niet snel een probleem worden. Als dat so belangrijk is, zit je waarschijnlijk toch al met een vrij speciaal stuk software.

ik denk niet alleen maar in termen van games hoor

Confusion schreef op maandag 16 juli 2007 @ 16:38:
En halverwege bedenken ze dat ze ook functionaliteit AA er bij willen, een koppeling met Foo en dat eigenlijk de database aan redesign toe is.

Als ze halverwege beseffen dat ze functionaliteit AA erbij willen, prima. Als ze dan pas bedenken dat er een koppeling met een ander systeem bij moet komen, en dat het "database design anders moet", dan heb je als software engineer echt je werk niet goed gedaan. Ik loop nu al een jaartje of 5 mee in de technische consultancy, heb bij een grote verscheidenheid aan klanten gewerkt, maar heb nog nooit meegemaakt dat ook maar in de buurt kwam van dat halverwege de database overhoop ging. Dat zou bij ons ook echt een kwestie van" "prima, 't is jouw geld :s" zijn.

Strooien mannen slaan ook nergens op.

Idd.

Bij onze klanten zijn er nog geen legers business process consultants en dergelijke langsgeweest. Die moet je helpen helder te krijgen wat ze willen. Daarbij ontdekken ze mogelijkheden en een maand later weten ze opeens dat ze 1 van die mogelijkheden willen realiseren. Gelukkig hebben wij daar dan rekening mee gehouden.

Ik geloof niet dat jullie rekening houden met extreme gevallen van een complexe database redesign. En als je die optie al openhoudt, neem ik aan dat je niet volgens een fixed-cost prijs werkt.

[ Voor 27% gewijzigd door Hydra op 16-07-2007 17:39 ]

[.oisyn]

FYI, ik heb zat webbased shit gemaakt, waaronder een compleet forum met min of meer dezelfde mogelijkheden als React wat hier draait. Verder ben ik bezig met een erg uitgebreid muziek-applicatie a la Buzz/Reason. Ik zit dus niet in een een of ander 3d-game-hol met totaal geen zicht op ander soort applicaties. Dit even ter info, omdat je steeds aan 3d games relateert (god mag weten waarom), wat in de context van de huidige discussie wel enorm slechte voorbeelden zijn

Hydra schreef op maandag 16 juli 2007 @ 17:35:
Het is echt helemaal niet moeilijk af te vangen. Als je ziet dat een gebruiker deeplinked zonder eerst op de frontpage langs te zijn geweest (via een crumb-trail ofzo), redirect je 'em gewoon terug naar start.

Ik zeg toch niet dat het niet af te vangen is? In mijn boekje heet dit juist in rare bochten moeten wringen om om de tekortkomingen van de omgeving heen te werken . Dat is waar we het namelijk over hebben. Om de UDP analogie van daarnet er maar even bij te pakken - je kunt ook wel gewoon streamed data middels UDP versturen, maar dat wil nog niet zeggen dat UDP uitermate geschikt is voor streamed data. Daar is TCP nou eenmaal voor.

Definieer 'dit soort doeleinden' alsjeblieft?

Een chat applicatie, bijvoorbeeld. Niet fatsoenlijk te doen met AJAX, daarvoor zul je een Java of .Net applet moeten embedden in je pagina. Ga me nou niet vertellen dat jij geen enkel zinnig voorbeeld kunt bedenken waarbij push nodig is ipv pull?

[Hydra]

.oisyn schreef op maandag 16 juli 2007 @ 17:48:
Een chat applicatie, bijvoorbeeld. Niet te doen met AJAX, daarvoor zul je een Java of .Net applet moeten embedden in je pagina. Ga me nou niet vertellen dat jij geen enkel zinnig voorbeeld kunt bedenken waarbij push nodig is ipv pull?

Tuurlijk, maar dat zijn weer redelijk specifieke voorbeelden. Ik ken weinig klanten die een chat-applicatie in hun frontoffice systeem willen Punt is dat webapps meestal prima voldoen.

En wat betreft dat 3D verhaal: ik probeer niet te zeggen dat je alleen daar verstand van hebt ofzo, het is alleen om aan te geven dat er ook duidelijk applicaties zijn welke niet erg goed in webapps te vatten zijn

[.oisyn]

Hydra schreef op maandag 16 juli 2007 @ 17:54:

Tuurlijk, maar dat zijn weer redelijk specifieke voorbeelden. Ik ken weinig klanten die een chat-applicatie in hun frontoffice systeem willen Punt is dat webapps meestal prima voldoen.

Maar meestal is niet altijd . Maar fair enough, de keren dat je echt push nodig hebt zijn natuurlijk gering. Desalniettemin ben ik van mening dat we in principe voortbouwen op een in mijn ogen inferieur systeem om dingen te doen waar het oorspronkelijk nooit voor ontworpen is. Ik snap wel dát het gebeurt, het "web" contept (HTTP, browsing, etc.) is immers een van de fundamenten van het internet en werkt out-of-the-box op vrijwel elke machine, en met technieken als AJAX kun je je website net wat beter en toegankelijker laten werken dan zonder. Maar voor volledige webapplicaties loop je al snel tegen die limieten aan (maar natuurlijk in het ene geval (chatapplicatie) wat meer dan in het andere geval (routeplanner a la maps.google.com))

En wat betreft dat 3D verhaal: ik probeer niet te zeggen dat je alleen daar verstand van hebt ofzo, het is alleen om aan te geven dat er ook duidelijk applicaties zijn welke niet erg goed in webapps te vatten zijn

Over het eerste punt: oh ok, zo kwam het een beetje over. Wat de rest betreft, helemaal mee eens (hoewel... )

[JKVA]

Hydra schreef op maandag 16 juli 2007 @ 17:54:
[...]


Tuurlijk, maar dat zijn weer redelijk specifieke voorbeelden. Ik ken weinig klanten die een chat-applicatie in hun frontoffice systeem willen Punt is dat webapps meestal prima voldoen.

En wat betreft dat 3D verhaal: ik probeer niet te zeggen dat je alleen daar verstand van hebt ofzo, het is alleen om aan te geven dat er ook duidelijk applicaties zijn welke niet erg goed in webapps te vatten zijn

In principe is elke toepassing van polling een workaround voor push AJAX. Met als voornaamste verschil dat de client direct controle kan uitoefenen op het verkrijgen van berichten, simpelweg door er niet meer om te vragen.

Er zijn al een aantal alternatieven voor polling zoals Comet en piggybacken. Feit is dat je niet echt MVC kunt doen met een webapplicatie als je met 'standaard AJAX' werkt. Hoewel de meesten er al aan gewend zijn is het toch jammer...

[flowerp]

Manuzhai schreef op maandag 16 juli 2007 @ 11:02:
[...]
Zodra je cookies hebt is het vrij straightforward om daar bovenop state te programmeren zoals jij dat prettig vindt.

Grapjas!

Ga jij me dan maar eens uitleggen hoe ik "vrij straightforward" door middel van cookies state kan bijhouden van verschillende views op de zelfde conversatie? (=dezelfde pages uit een pageflow in b.v. verschillende tabs/windows openen).

Nadat je dat gedaan hebt, mag je me meteen ook even uitleggen hoe ik d.m.v. cookies "vrij straightforward" het gebruik van de backbutton en een daaropvolgende post kan ontdekken en/of voorkomen (double commit problem).

Misschien dat jouw manier van cookie gebruik om deze problemen "vrij straightforward" op te lossen zo revolutionair is, dat je ook even Gavin King van de Web Beans JSR een mailtje kan sturen. Dan kan ie meteen de 1000'en regels code in SEAM droppen om dit te realiseren en hoeft ie ook niet een dik jaar verder te werken om deze techniek te perfectioneren.

[Hydra]

flowerp schreef op dinsdag 17 juli 2007 @ 01:33:
[...]


Grapjas!

Ga jij me dan maar eens uitleggen hoe ik "vrij straightforward" door middel van cookies state kan bijhouden van verschillende views op de zelfde conversatie? (=dezelfde pages uit een pageflow in b.v. verschillende tabs/windows openen).

Hij bedoelt dat als je cookies hebt, je een session state bij kunt houden server-side, en dat het dan vrij simpel is om te bepalen of een state valid is of niet.

[farlane]

Ik merk dat er hier een aantal mensen zijn die hun web/http/AJAX vurig verdedigen en bij bijna elk nadeel dat wordt opgenoemd een "oplossing" wordt aangedragen. ( bijna omdat bij bijvoorbeeld het gebrek aan een goed push mechanisme wordt gezegd 'welke klant wil dat nou', das imho geen oplossing )

Mijn ervaringen zijn dat klanten bij webapplicaties eigenlijk dezelfde gebruikerservaring willen als bij een desktop applicatie, feit is dat om daar bij in de buurt te kunnen komen je mechanismen ( bijv ajax ) moet gebruiken. En dan nog kun je niet dezelfde ervaring bereiken. Komt nog bij dat al die technieken bij elkaar het geheel er niet bepaald overzichtelijker op maken.

Ik vraag me eigenlijk een beetje af wanneer de webgoeroes ( want dat ben ik absoluut niet laat ik dat voorop stellen ) willen toegeven dat iets een workaround ( hoe knap het ook bedacht mag zijn ) is en eigenlijk een tekortkoming van 'het web' ?

[flowerp]

Hydra schreef op dinsdag 17 juli 2007 @ 11:56:
[...]
Hij bedoelt dat als je cookies hebt, je een session state bij kunt houden server-side, en dat het dan vrij simpel is om te bepalen of een state valid is of niet.

Dat "vrij simpel" is gewoon niet waar.

Een cookie is een heel grof mechanisme. Het is niets meer of minder dan 1 key-value pair die in de HTTP request header voor elke request naar een domain of sub-domain wordt gestuurd.

Om zoiets 'schraals' als basis voor een stateful application te gebruiken is gewoon -heel- erg veel werk. In de huidige web frameworks moesten we wel, want het was zo'n beetje de enige houvast die we hadden (het alternatief is URL rewriting, waar je nog minder gelukkig van wordt).

Als ik even Java EE als uitgangspunt neem (dezelfde principes gelden voor andere platformen als ASP.NET, etc), dan is er allereerst de Servlet API die bovenop de cookie bouwt. Deze alleen al heeft enkele jaren gekost om te ontwikkelen en nog wat jaren meer om te perfectioneren.

Met de servlet API kun je state al iets meer finegrained bijhouden; effectief krijg je bovenop de cookie een session scope, een request scope, en een page scope. Helaas zijn deze voor de meeste toepassingen nog steeds te grof. Session scope houdt data bij gerelateerd aan alle requests van 1 gebruiker, terwijl request scope data bij houdt gerelateerd aan 1 enkele request. Dikwijls is session scope veels te groot en request scope te klein.

Stel je de volgende situatie voor; een 3-tal pages om een hotel uit te zoeken, te selecteren en te boeken. Ik moet data tussen pages bewaren, dus ik kies voor de session scope. Een gebruiker kiest een hotel uit, maar voordat ie voor boeken kiest besluit ie in een andere tab nog even een ander hotel te bekijken. Geschrokken van de prijzen besluit ie toch maar voor de eerste keus te gaan, gaat terug naar de eerste tab en bevestigt de boeking. BOEM. Gebruiker heeft het verkeerde hotel geboekt omdat het vorige hotel nog in de sessie scope stond, en mijn server nix van de 'stiekume' navigatie van de gebruiker af weet.

Wat doen we nu dus?

We slaan de state op in de afzonderlijke pagina's en sturen deze telkens heen en weer. Alsof dit opzich al niet veel gedoe is, zit je ook nog met het feit dat je je Java datastructuren telkens moet serializen en weer de-serializen. In Java EE zit er daarom nog een layer bovenop de Servlet API; de JSF API met oa een (pluggable) StateManager die dit voor je regelt. In de JSF API heeft echter ook alweer velen jaren werk gezeten en zal nog eens velen jaren gaan zitten om het te perfectioneren.

Met de JSF API en een simpele hulp-tag uit TomaHawk (savestate) kan ik state tussen pagina requesten bijhouden binnen 1 'conversation', maar het blijft een heel gedoe. Als ik state op de client (in de pagina's) save kan ik er niet al te grote dingen in stoppen, save ik alleen IDs op de page die verwijzen naar een structuur op de server, dan kom ik mogelijk in de problemen met memory op de server.

Namelijk, via HTTP weet ik nooit of een gebruiker de browser window of tab nog daarwerkelijk open heeft. Ik moet dus in de praktijk veels te veel dingen bewaren (dit probleem heb je overigens ook bij alleen de session scope).

Alsof dit nog niet genoeg problemen oplevert, kan de gebruiker ook nog eens de page midden in de conversation 'refreshen' door alleen in de addressbar op enter te drukken -> weg state.

Vanwege al dit handmatige gedoe met savestate tags, doen nog steeds veel mensen dit fout en blijven er veel gaten in implementaties van dergelijke conversaties zitten. Op naar de volgende layer dan maar weer: Web Beans. Deze zal een kant & klare conversation scope toevoegen. Natuurlijk kost de ontwikkeling hiervan ook weer enkele jaren en zal het ongetwijfeld daarna nog enkele jaren kosten om de onvolkomenheden eruit te halen.

Op welk punt was state ook alweer vrij makkelijk met cookies bij te houden????

Weet je wat makkelijk, krachtig en volkomen intuïtief is?

De manier waarop het in de desktop applicaties gebeurd. Ik instantieer een dialog en geef deze een referentie (pointer) mee naar een structuur waar de data in moet komen.

That's it.

Geen gotcha's, geen moeilijke dingen. Gewoon een pointer naar een structuur die ik direct kan benaderen en die alleen voor die dialoog gebruik wordt. Wil de gebruiker tegelijk een andere dialoog open hebben, dan maak ik een compleet onafhankelijk instantie aan met een referentie naar een compleet onafhankelijke data structuur.

Een aantal van de bovengenoemde problemen is direct terug te voeren op het HTTP protocol zelf. Cookies zijn in te stellen per domain, of per sub-domain, maar niet per window of per tab en het protocol heeft zelf geen mogelijkheden om door te geven dat een window afgesloten is, of dat er een back navigatie of refresh heeft plaatsgevonden, of dat een click voortkomt uit een window waarvoor de originele request in 'sessie request nummer 23' was gedaan, etc etc etc.

Al met al is de industrie nu al een ruim tien jaar bezig om een voor de programmeur stateful model bovenop de cookie te bouwen, en hoewel we ver gekomen zijn, zijn we er nog lang niet. Misschien over 5 jaar... wie weet.

"vrij simpel" ???

[curry684]

farlane schreef op dinsdag 17 juli 2007 @ 12:44:
Ik vraag me eigenlijk een beetje af wanneer de webgoeroes ( want dat ben ik absoluut niet laat ik dat voorop stellen ) willen toegeven dat iets een workaround ( hoe knap het ook bedacht mag zijn ) is en eigenlijk een tekortkoming van 'het web' ?

Het web is met heel goede reden opgezet als stateless connectionless systeem. Ik zie niet echt in hoe dat een tekortkoming van het web an sich is, en hoe dan XHR-technologie tot een workaround maakt, ondanks dat het voor zich spreekt dat HTTP 1.2 of 2.0 best ondersteuning zou mogen krijgen voor stateful bi-directional communicatie.

Dat er in theorie betere oplossingen mogelijk zijn met volledig nieuwe technologie betekent nog niet dat bestaande oplossingen middels andere technologie per definitie fout of workaround zijn.

[JKVA]

Ik probeer me een beeld te vormen van wat stateful http nou eigenlijk is, maar het lukt nog steeds niet helemaal. flowerp is de eerste die een aanzet doet voor een oplossing, want ik hoor steeds alleen de term stateful http en niet wat daarmee bedoeld wordt.

Blijkbaar is stateful http dus dat bij elk event dat mogelijkerwijs kan gebeuren, een bericht naar de server gaat om iets bij te werken. Zoals een windowclose, etc. maar wat lost dat op? Volgens mij heeft heel de discussie niets met http te maken, maar met het feit dat je je applicatie embed in een andere applicatie - namelijk de browser - en die 'parent' applicatie kan direct op het laagste niveau invloed uitoefenen op jouw applicatie.

In een client applicatie (zoals iets met swing ofzo) kun je ook je venster sluiten, of een back button functionaliteit inbouwen, of nog leuker, een tekstveld waarmee je direct naar een scherm kunt springen en met ? en & willekeurige parameters kunt meegeven (sounds familiar?). Er is in deze context maar één verschil tussen deze alinea en een willekeurige webapplicatie, namelijk dat de ontwikkelaar van een client applicatie zelf de functionaliteiten inbouwt en er voor zorgt dat het goed wordt verwerkt en dat bij een client-server/webapplicatie deze functionaliteiten gratis en voor niks worden meegeleverd.

Dat is het hele probleem, dat de communicatielaag volledig open is. Je kunt alle berichten faken en dergelijke en daar kan de applicatie niet mee om omdat een mens simpelweg niet met alles rekening kan houden. Bij een client applicatie heb je dat probleem niet, want het OS staat het niet toe dat iedereen in elkaars memory zit te schrijven en lezen...

[flowerp]

JKVA schreef op dinsdag 17 juli 2007 @ 17:27:
Blijkbaar is stateful http dus dat bij elk event dat mogelijkerwijs kan gebeuren, een bericht naar de server gaat om iets bij te werken. Zoals een windowclose, etc. maar wat lost dat op? Volgens mij heeft heel de discussie niets met http te maken

Volgens mij juist wel. Je wilt niet elk event naar de server hebben, maar wel events m.b.t. je connection management. Window close is daarbij wel degelijk een belangrijk event; als de server state bijhoudt voor een conversation in die window kunnen de resources daarvoor vrijgegeven worden.

Het zelfde geldt voor het identificeren van windows en tabs. Zoiets wil je niet in HTML en/of javascript regelen, maar heeft weer te maken met connection management en is dus typisch iets wat je in het onderliggende HTTP protocol kunt regelen. Het is ook niet eens zo bijzonder vergezocht; nu identificeer je per domein al een gehele browser door de cookie entry in je HTTP header. Je kunt dit concept vrij makkelijk uitbreiden door 1 field in je header toe te voegen voor identificatie van aparte windows/tabs binnen een browser.

Een statefull connection zegt eigenlijk niets meer dan dat de server alle data die over die connectie gaat kan associëren als bij elkaar horend. Als ik bijvoorbeeld inlog via SSH op een server, dan identificeert elke chunk data die ik later stuur naar die server als horend bij die ene inlog.

Voor een statefull connection -moet- een server iets van data bijhouden gerelateerd aan die connection. Ook kost het initialiseren daarvan iets aan tijd. Voor een web applicatie gebeurd dat meestal sowieso al, dus zou het niet uitmaken. Voor websites die statische content serveren of geen state hoeven bij te houden zou het echter vervelend zijn als het perse zou moeten.

Een mogelijke oplossingen zou zijn dat er optioneel onderhandelt kan worden om een stateless HTTP request up te graden naar een stateful connection. In feite doe je zoiets nu al serverside als je besluit wel of geen "session" aan te maken. Voor strikt eenrichtingsverkeer is deze connection negotiation upgrade echter nog niet eens perse noodzakelijk; een betere identificatie van de requesten zou al heel veel pijnpunten weghalen.

[JKVA]

flowerp schreef op dinsdag 17 juli 2007 @ 19:38:
[...]


Volgens mij juist wel. Je wilt niet elk event naar de server hebben, maar wel events m.b.t. je connection management. Window close is daarbij wel degelijk een belangrijk event; als de server state bijhoudt voor een conversation in die window kunnen de resources daarvoor vrijgegeven worden.

Het zelfde geldt voor het identificeren van windows en tabs. Zoiets wil je niet in HTML en/of javascript regelen, maar heeft weer te maken met connection management en is dus typisch iets wat je in het onderliggende HTTP protocol kunt regelen. Het is ook niet eens zo bijzonder vergezocht; nu identificeer je per domein al een gehele browser door de cookie entry in je HTTP header. Je kunt dit concept vrij makkelijk uitbreiden door 1 field in je header toe te voegen voor identificatie van aparte windows/tabs binnen een browser.

Een statefull connection zegt eigenlijk niets meer dan dat de server alle data die over die connectie gaat kan associëren als bij elkaar horend. Als ik bijvoorbeeld inlog via SSH op een server, dan identificeert elke chunk data die ik later stuur naar die server als horend bij die ene inlog.

Voor een statefull connection -moet- een server iets van data bijhouden gerelateerd aan die connection. Ook kost het initialiseren daarvan iets aan tijd. Voor een web applicatie gebeurd dat meestal sowieso al, dus zou het niet uitmaken. Voor websites die statische content serveren of geen state hoeven bij te houden zou het echter vervelend zijn als het perse zou moeten.

Precies, maar dat lost (bij Java) de Servlet spec al voor je op door een http sessie aan te bieden. Wat biedt stateful http dan bovenop een sessie? Behalve de window close. Je zult zelf nog steeds je valide states e.d. moeten programmeren en dan maakt "stateful http" of stateless http met session in mijn optiek geen verschil. Al die rare events die niet in een webapplicatie thuis horen, zoals back, refresh en bookmark moet je sowieso custom programmeren, want misschien wil je die-zware-query-achter-die-ene-specifieke-pagina wel cachen of een andere actie, specifiek voor jouw situatie.

Volgens mij is een window close event ook geen verschil bedenk ik me trouwens, aangezien de sessie op twee plaatsen bewaard wordt. Server en cookie. Mist 1 van die 2, dan wordt een nieuwe sessie gestart. Cookie is weg bij een window close actie, dus het netto resultaat is volgens mij precies hetzelfde als een een window close event op de stateful manier die je beschrijft.

Maar misschien zie ik iets over het hoofd?

Een mogelijke oplossingen zou zijn dat er optioneel onderhandelt kan worden om een stateless HTTP request up te graden naar een stateful connection. In feite doe je zoiets nu al serverside als je besluit wel of geen "session" aan te maken. Voor strikt eenrichtingsverkeer is deze connection negotiation upgrade echter nog niet eens perse noodzakelijk; een betere identificatie van de requesten zou al heel veel pijnpunten weghalen.

Die associatie is idd nuttig, maar ik zie er vooral nut in als client en server een daadwerkelijke 'conversatie' willen starten, ofwel een server die berichten direct naar de client kan sturen. Volgens mij ligt daar het grootste probleem, namelijk dat het altijd request-response gebaseerd is en niet direct response. Als ik eenmaal een connectie heb opgezet met een server en misschien nog iets met security, vind ik het best als die server mij op eigen initiatief berichten stuurt. Daar ligt echter een probleem, namelijk a) firewalls die het niet toelaten en b) clients die niet als server zijn ingericht en dus niet op een poort luisteren naar de berichten die de server op eigen initiatief stuurt.

[flowerp]

JKVA schreef op dinsdag 17 juli 2007 @ 19:59:
[...]
Precies, maar dat lost (bij Java) de Servlet spec al voor je op door een http sessie aan te bieden. Wat biedt stateful http dan bovenop een sessie?

Dat heb ik toch al meerdere keren gezegd? State per connectie (window/tab) i.p.v. gedeelde state voor al je connecties (windows/tabs).

[curry684]

flowerp schreef op dinsdag 17 juli 2007 @ 20:37:
[...]


Dat heb ik toch al meerdere keren gezegd? State per connectie (window/tab) i.p.v. gedeelde state voor al je connecties (windows/tabs).

Not to mention dat cookies enorm eenvoudig te hijacken zijn, in tegenstelling tot bidirectionele TCP-verbindingen die je in beginsel zonder MitM niet op ingebroken komt, en dan nog aardig omslachtig.

[farlane]

JKVA schreef op dinsdag 17 juli 2007 @ 19:59:
Daar ligt echter een probleem, namelijk a) firewalls die het niet toelaten en b) clients die niet als server zijn ingericht en dus niet op een poort luisteren naar de berichten die de server op eigen initiatief stuurt.

Huh? Je firewall is toch ook stateful? Volgens mij weet die precies welke requests/responses bij elkaar horen.

[curry684]

farlane schreef op woensdag 18 juli 2007 @ 09:50:
[...]


Huh? Je firewall is toch ook stateful? Volgens mij weet die precies welke requests/responses bij elkaar horen.

Hangt van het model af hoe je dit interpreteert. JKVA refereert (foutief imho) aan het active FTP-model, waarbij afzonderlijke server-initiated data-channels worden ingezet naast het communicatiechannel. Ik refereerde zelf aan het gangbare TCP-stream-model waarbij 1 of meerdere persistent client-initiated channels de communicatie met de server verzorgen.

Een stateful firewall impliceert dat hij onthoudt welke local ports een connectie naar de buitenwereld geopend hebben zodat hij vervolgens van de betreffende IP/port combinaties data terug toestaat door de firewall. Dit is 'nogal' vitaal voor bidirectionele communicatie van SMTP tot FTP tot HTTP.

[JKVA]

curry684 schreef op woensdag 18 juli 2007 @ 10:30:
[...]

Hangt van het model af hoe je dit interpreteert. JKVA refereert (foutief imho) aan het active FTP-model, waarbij afzonderlijke server-initiated data-channels worden ingezet naast het communicatiechannel. Ik refereerde zelf aan het gangbare TCP-stream-model waarbij 1 of meerdere persistent client-initiated channels de communicatie met de server verzorgen.

Een stateful firewall impliceert dat hij onthoudt welke local ports een connectie naar de buitenwereld geopend hebben zodat hij vervolgens van de betreffende IP/port combinaties data terug toestaat door de firewall. Dit is 'nogal' vitaal voor bidirectionele communicatie van SMTP tot FTP tot HTTP.

FTP? Hmm, kan me niet herinneren dat ik dat geroepen heb. Ff teruglezen.

Even later terug: "Nee, kan het nog steeds niet herinneren."

Maar goed. Ik refereer dus niet naar FTP. Weet ook niet hoe je daar bij komt. Waar ik op doel is dat je - zonder technieken voor reverse AJAX zoals Comet en polling - momenteel geen site als Alex kunt maken (volgens mij was het Alex) die nieuwe data toont wanneer deze beschikbaar is. Die server stuurt in principe voor een request één bericht terug. En niet over 5 minuten weer eentje, en na een kwartier weer eentje, etc.

Volgens mij is een dergelijke push methode essentieel om een goede MVC implementatie te maken op het web. Het gaat mij er niet om of ik een nieuw http protocol gebruik, ofwel een bestaand protocol met wat extra lagen erboven. Mij gaat het erom dat het voor mij als applicatieontwikkelaar gemakkelijk is om een goed programmeermodel te implementeren dat tegelijk vrij efficient is.

Als dat met stateful http kan, prima. Als dat met stateless http + Servlets + JSF + Seam kan, ook goed, zolang ik er maar op een fatsoenlijke manier goede software mee kan bouwen die aan de wensen van de klant voldoet, binnen tijd en binnen budget is. Die extra lagen boeien me in principe niet zo veel, als het maar goed werkt. TCP/IP heeft bijvoorbeeld ook veel lagen, dat maakt me ook niet uit.

[curry684]

JKVA schreef op woensdag 18 juli 2007 @ 22:06:
[...]

FTP? Hmm, kan me niet herinneren dat ik dat geroepen heb. Ff teruglezen.

Even later terug: "Nee, kan het nog steeds niet herinneren."

Maar goed. Ik refereer dus niet naar FTP. Weet ook niet hoe je daar bij komt.

Jij had het over clients die niet als server zijn ingericht en door firewalls geen incoming traffic accepteren, oftewel dat de server een verbinding naar een clientside TCP socket initieert. Dat is een idioot netwerkmodel dat alleen in FTP gebruikt wordt, vandaar dat ik het het FTP-model noemde.

Volgens mij is een dergelijke push methode essentieel om een goede MVC implementatie te maken op het web. Het gaat mij er niet om of ik een nieuw http protocol gebruik, ofwel een bestaand protocol met wat extra lagen erboven. Mij gaat het erom dat het voor mij als applicatieontwikkelaar gemakkelijk is om een goed programmeermodel te implementeren dat tegelijk vrij efficient is.

Als dat met stateful http kan, prima.

Als je jouw aanname van server-initiated connections omdraait in een client die de verbinding met de server niet verbreekt of pauzeert na iedere request, heb je dus een server die op eigen initiatief data naar de client kan sturen. Zonder firewall problemen. Waarmee je events op de client kunt definieren die op nieuwe data vanuit de server real time reageren, en je dus per definitie stateful bezig kunt zijn. Dat is dus het model wat ik in mijn post omschreef

[Verwijderd]

Hydra schreef op maandag 16 juli 2007 @ 17:35:
Wat betreft dat niet kunnen pushen: tja, ik zie dat niet snel een probleem worden. Als dat so belangrijk is, zit je waarschijnlijk toch al met een vrij speciaal stuk software.

Neem een willekeurige multi-user applicatie die bv. een gezamenlijke voorraad aan resources heeft. Bij een push-applicatie kun je bv. iedere client vertellen dat die laatste hotelkamer net door een andere user verkocht is, bij een pull-only applicatie komt de gebruiker daar pas achter wanneer 'ie probeert die kamer die 5 minuten geleden nog beschikbaar was te boeken.

Idem voor vliegtuigstoelen, huurauto's, etc. Noem maar op. En dan zit je misschien wel op "een vrij speciaal stuk software", maar tegelijkertijd ook op een hele grote markt.

[JKVA]

curry684 schreef op woensdag 18 juli 2007 @ 22:19:
[...]

Jij had het over clients die niet als server zijn ingericht en door firewalls geen incoming traffic accepteren, oftewel dat de server een verbinding naar een clientside TCP socket initieert. Dat is een idioot netwerkmodel dat alleen in FTP gebruikt wordt, vandaar dat ik het het FTP-model noemde.

[...]

Als je jouw aanname van server-initiated connections omdraait in een client die de verbinding met de server niet verbreekt of pauzeert na iedere request, heb je dus een server die op eigen initiatief data naar de client kan sturen. Zonder firewall problemen. Waarmee je events op de client kunt definieren die op nieuwe data vanuit de server real time reageren, en je dus per definitie stateful bezig kunt zijn. Dat is dus het model wat ik in mijn post omschreef

Ja, nu begrijpen we elkaar volgens mij. (duurt soms ff ) Die optie ken ik idd, maar dan is het niet echt schaalbaar meer aangezien elke client zijn connectie open laat staan. In feite komt dat overeen met de Comet techniek die er via een truc voor zorgt dat de connectie open blijft.

[orf]

Opera heeft al push. Mijn verwachting is dat andere browsers wel gaan volgen. Het web is nog jong; features komen vanzelf wel. Zij het dat het iets langer duurt dan je zou willen.

[Verwijderd]

.oisyn schreef op maandag 16 juli 2007 @ 17:48:
Een chat applicatie, bijvoorbeeld. Niet fatsoenlijk te doen met AJAX, daarvoor zul je een Java of .Net applet moeten embedden in je pagina. Ga me nou niet vertellen dat jij geen enkel zinnig voorbeeld kunt bedenken waarbij push nodig is ipv pull?

Ik zal niet ontkennen dat push verdomd handig zou zijn bij het bouwen van een webbased chat app maar om nou te zeggen dat het niet te doen is vind ik overdreven.

[.oisyn]

Niet fatsoenlijk te doen zei ik. Een chat applicatie dmv pull vind ik niet fatsoenlijk. Dan moet je een afweging maken tussen responsiveness en serverload.

[ Voor 64% gewijzigd door .oisyn op 20-07-2007 17:28 ]

[Orphix]

Het HTTP protocol voldoet goed voor datgeen waarvoor het oorspronkelijk gemaakt is: het serveren van tekst pagina's. Bedenk dat in die tijd het client/server paradigma nog heel erg actief was, als opvolger van het 'domme terminal, slimme server' concept. HTTP is uitgevonden in de tijd dat breedband nog smallband was.

Ik denk dat met de opkomst van steeds sneller internet deze constraints langzaamaan verdwijnen. Het remote werken is heel erg in opmars. Virtuele servers en virtuele desktops heeft steeds meer belangstelling. Daarnaast worden de ontwikkelplatformen steeds geavanceerder, waarbij de grens tussen desktop ontwikkeling en web ontwikkeling steeds kleiner wordt. Ik heb het hier dan vooral over het windows platform, aangezien ik daar op dagelijkse basis mee werk. De opkomst van silverlight is voor mij niet enkel een 'flash vervanger', maar het begin van de mogelijkheid om straks complete applicaties op het .NET framework in een browser te laten zien. Met alle voordelen van websites uiteraard: single-point configuratie, eenvoudige deployment, eenvoudig versiebeheer, laagdrempelig, etc.

Dus als je mij vraagt wat dan het alternatief zou zijn voor HTTP? Ik vermoed geen ander protocol. We gaan straks of gewoon weer terug naar een continue verbinding voor stateful applicaties. Of we worden op onze pc gepresenteerd op een kijkvenster naar de 'slimme server'.

[JKVA]

.oisyn schreef op vrijdag 20 juli 2007 @ 17:27:
Niet fatsoenlijk te doen zei ik. Een chat applicatie dmv pull vind ik niet fatsoenlijk. Dan moet je een afweging maken tussen responsiveness en serverload.

En dan is een oplossing op http niveau misschien een optie, want anders krijg je een wildgroei met lagen/patterns erbovenop.

Alleen jammer dat je bij bijvoorbeeld een stateful http van die dure connecties krijgt, omdat je ze in leven moet houden. Aan de andere kant is dat misschien beter dan allemaal kleine connecties steeds achter elkaar wat je met polling hebt. Het zal van de implementatie afhangen of een "nieuwe http" een oplossing is denk ik...

[flowerp]

Orphix schreef op zaterdag 21 juli 2007 @ 00:46:
De opkomst van silverlight is voor mij niet enkel een 'flash vervanger', maar het begin van de mogelijkheid om straks complete applicaties op het .NET framework in een browser te laten zien. Met alle voordelen van websites uiteraard: single-point configuratie, eenvoudige deployment, eenvoudig versiebeheer, laagdrempelig, etc.

Inderdaad, Silverlight klinkt als een zeer interessante techniek en ik ben benieuwd wat dit voor web applicaties daadwerkelijk gaat doen. In de opensource (java) wereld zijn er diverse initiatieven die wel een beetje zoiets doen, maar het net niet zijn of telkens net niet helemaal van de grond komen (wingS, Echo, gedeeltelijk ook java webstart).

Voor een 'logge monopolist' is Microsoft in ieder geval voor developers toch wel goed bezig de laatste tijd (directX 10, xbox 360 en dus ook silverlight).

[Verwijderd]

JKVA schreef op zondag 22 juli 2007 @ 11:53:
[...]

En dan is een oplossing op http niveau misschien een optie, want anders krijg je een wildgroei met lagen/patterns erbovenop.

Alleen jammer dat je bij bijvoorbeeld een stateful http van die dure connecties krijgt, omdat je ze in leven moet houden. Aan de andere kant is dat misschien beter dan allemaal kleine connecties steeds achter elkaar wat je met polling hebt. Het zal van de implementatie afhangen of een "nieuwe http" een oplossing is denk ik...

HTTP is niet het enige probleem. De meeste browsers ondersteunen het oneindig openhouden van een connectie ook niet. De enige voorbeelden van push die ik tot nu toe heb gezien zijn (imo) nog lelijker dan polling:

- Verstuur in een IFRAME een request naar de push streamer
- Deze stuurt een HTML-pagina terug
- Deze pagina 'eindigt' nooit en bestaat alleen uit <script></script> blokken waarin de gepushte berichten staan en de code die callbacks verzorgt

Mijn voorkeur (als front-end programmeur) gaat dan toch echt uit naar Ajax+polling

We hebben dus ook zeker een client-side component nodig die 'netjes' met push om kan gaan.

Volgens mij zijn er trouwens ook nog wel problemen met firewalls en proxy's, ed. maar daar heb ik me nooit echt in verdiept.

[JKVA]

Verwijderd schreef op woensdag 25 juli 2007 @ 23:59:
[...]

HTTP is niet het enige probleem. De meeste browsers ondersteunen het oneindig openhouden van een connectie ook niet. De enige voorbeelden van push die ik tot nu toe heb gezien zijn (imo) nog lelijker dan polling:

- Verstuur in een IFRAME een request naar de push streamer
- Deze stuurt een HTML-pagina terug
- Deze pagina 'eindigt' nooit en bestaat alleen uit <script></script> blokken waarin de gepushte berichten staan en de code die callbacks verzorgt

Mijn voorkeur (als front-end programmeur) gaat dan toch echt uit naar Ajax+polling

We hebben dus ook zeker een client-side component nodig die 'netjes' met push om kan gaan.

Volgens mij zijn er trouwens ook nog wel problemen met firewalls en proxy's, ed. maar daar heb ik me nooit echt in verdiept.

Of Adobe Flex. Die ondersteunt native een push mechanisme via de Flash plugin. Dat is echter niet op HTTP gebaseerd heb ik begrepen.

[H!GHGuY]

Je kan de analogie van stateless HTTP met stateful X (cookies bvb) helemaal doortrekken naar andere dingen. TCP over IP bijvoorbeeld. IP is stateless: _een_ pakketje moet van _punt A_ naar _punt B_.
TCP heeft state: connectie is open, X bytes verzonden, Y ontvangen, etc.

Mag je dan IP niet gebruiken wil je een stateful verbinding opzetten tussen 2 hosts?
HTTP voldoet prima. Cookies voldoen prima. AJAX voldoet prima.

Ander voorbeeld:
het Windows API messaging systeem. Nemen we nu een asynchrone response-reply message combinatie om de vergelijking met HTTP te kunnen behouden. Elke request/reply combinatie is stateless. Maar de laag erboven die ze gebruikt heeft (ik mag het althans hopen) wel state.

Punt is en blijft dat protocols slechts een middel zijn. Ze hebben elk voor en nadelen dus wanneer je iets nieuws wilt kies je best een protocol waar je zoveel mogelijk voordeel uithaalt en je zo weinig mogelijk extra voor moet doen. cookies binnen HTTP zijn volgens mij dus zeker geen "bochten wring werk."

[lzandman]

ATS schreef op zaterdag 14 juli 2007 @ 06:32:
Kortom: ik zou het een paradigma willen noemen.

Inderdaad. ATS is een van de weinigen in dit topic die het begrepen heeft...

[JKVA]

lzandman schreef op maandag 30 juli 2007 @ 00:36:
[...]

Inderdaad. ATS is een van de weinigen in dit topic die het begrepen heeft...

Heb je het hele topic wel gelezen? De discussie gaat helemaal niet meer over het feit of XMLHTTP een taal, tool of wat dan ook is.

In de ogen van een aantal is het een lapmiddel wat eigenlijk door het onderliggende protocol gestandaardiseerd moet worden (zoals de discussie stateful HTTP). In de ogen van anderen (incl. ondergetekende) is het geen echt lapmiddel, maar gewoon een 'nieuwe' manier van werken die gewoon nog even volwassen moet worden. Bijvoorbeeld op het gebied van cross browser ondersteuning.

Ofwel de discussie ligt al helemaal ergens anders. Ik neem aan dat hier (ik schat de gemiddelde tweaker vrij hoog in) vrijwel niemand denkt dat AJAX een taal is, maar manier van werken. XMLHTTP is puur een middel om het toe te passen. De taal blijft JavaScript + PHP/Java/ASP......

[NMe]

lzandman schreef op maandag 30 juli 2007 @ 00:36:
[...]

Inderdaad. ATS is een van de weinigen in dit topic die het begrepen heeft...

Dankjewel voor deze bijzonder zinnige, inhoudelijke post. Een grapje op zijn tijd kan leuk zijn, maar als je verder niks zinnigs te melden hebt, post dan niet.