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

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.

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..)

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 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.

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 ]

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.

Vraag me af wanneer web 3.0 gereleased gaat worden.

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.

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 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.

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 )

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.

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?

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.

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

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 ]

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.

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.

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?

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.

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

http = http, de p staat overigens voor protocol.

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.

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.

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 ]

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

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?

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 ]

.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.

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 ]

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?

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 ]

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.

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.

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.

En nog meteen een move naar SEA ook

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.

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...

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 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?

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.

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...

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.

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.).

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 .

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.

.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.

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

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.

.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 ]

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?

.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

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... )

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...

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.

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.

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' ?

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" ???

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.

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...

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.

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.

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).

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.

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.

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.

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.

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

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.

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.

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.

.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.

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 ]

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'.

.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...

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).

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.

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.

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."

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...

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......

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.

funkwurm schreef op zondag 05 augustus 2007 @ 06:20:
Daarnaast wil ik het volgende toevoegen aan de discussie, een aantal tweakers hoor ik klagen over dat de browser een back-button heeft en favorieten en dat dat hun applicatie in de weg loopt. [...]. Voor mensen in bijvoorbeeld callcenters voegt dat een stuk usability toe, neem dat niet weg omdat het niet in jou beeld van de applicatie-flow past. Dat beeld is gebaseerd op jou referentiekader van het database-model en de verdere back-end, niet op ervaring met een boze klant aan de lijn die je snel wil helpen.

Als je dat denkt dan heb je of de discussie niet goed begrepen, of niet goed gelezen.

Het concept van een back-button is helemaal niet het probleem waar web-developers over klagen. Het gaat om de implementatie hiervan (en de non-support ervoor qua protocol) in de huidige web-browsers.

Bij het gebruik van de backbutton lopen de client en de server uitelkaar, zonder dat de server hier weet van kan hebben. Bij een volgende request vanuit een venster waarin de back-button werd gebruikt, moeten er veel synchronisatie checks plaatsvinden. Dit is een hoop 'gedoe' en werkt lang niet altijd goed als je niet heel goed oplet.

Het hele punt van de discussie was hem nou juist dat al dat 'gedoe' eigenlijk niet had gehoeven wanneer we een beter protocol en/of platform hadden gehad. Ter vergelijking; ik heb enkele plug-ins
voor de Eclipse omgeving ontwikkeld. Voor oa de preferences kent deze ook de back-button. In tegenstelling tot de web-browser werkt het programmeer-model hier gewoon wel goed.

funkwurm schreef op zondag 05 augustus 2007 @ 14:49:
[...]
Maar ik kan zo'n voorbeeld niet bedenken, je kunt als het moet de volledige pagina verwijderen en opnieuw opbouwen met DOM-bewerkingen zonder een nieuwe pagina aan te roepen, waarmee die dynamisch gecreëerde pagina nooit plotseling in de history of de favorieten terecht komt.

Dat ontneem je de gebruiker juist de back-button en dat wilde je juist niet. Ik herhaal: het is niet het concept van de back-button wat broken is maar de implementatie ervan in het huidige HTTP protocol en de huidige web browsers.

flowerp schreef op zondag 05 augustus 2007 @ 15:03:

Dat ontneem je de gebruiker juist de back-button en dat wilde je juist niet. Ik herhaal: het is niet het concept van de back-button wat broken is maar de implementatie ervan in het huidige HTTP protocol en de huidige web browsers.

De back button heeft echt niks met het HTTP protocol te maken. Er wordt nergens in dat protocol iets over geschreven, en is dus niet eens verplicht voor user agents. Logisch ook, want in feite is elke HTTP client een user agent, dus ook spiders van zoekmachines en dergelijke. Waarom zou in dat protocol moeten worden vastgelegd wat een client wel of niet zou moeten bieden aan functionaliteit?

Waarom zou een user agent niet kunnen nagaan of een webapplicatie bepaalde punten heeft waarin de complete state kan worden vastgelegd, waarmee de user agent dus iets met een back button kan? Dat bestaat nu helemaal niet, voor zover ik weet. Maar dat heeft nog altijd niets met het HTTP protocol te maken. Dat gebeurt op een "pagina" die door de user agent is geladen. Of dat nou vanaf de harddisk of via HTTP of via FTP of whatever is gedaan, moet toch niet uitmaken?

Nog 1 keer: het HTTP protocol is echt niet b0rked. De implementatie soms een beetje, maar dat staat los van waar het nu over gaat, en heeft niets te maken met back buttons, waar HTTP terecht geen weet van heeft.

Verwijderd schreef op zondag 05 augustus 2007 @ 15:54:
[...]
De back button heeft echt niks met het HTTP protocol te maken.

Correctie: de back button heeft echt niks met het HUIDIGE HTTP protocol te maken.

Ik heb al een aantal mogelijk oplossingen genoemd die in het HTTP protocol de problemen met de back button zouden kunnen verbeteren, waaronder een sequence nummer, zodat de server weet of een click vanuit de huidige pagina komt, of vanaf een pagina die is bereikt via de back button.

Een andere mogelijkheid is het doorgeven van het gebruik van de back button, als de server hierom gevraagd heeft.

Als ik in Eclipse de back button gebruik dan -weet- mijn code dat ogenblikkelijk en kan ik diverse acties ondernemen. Het HTTP protocol heeft hier geen support voor. Met Javascript kan je soms er om heen werken, maaruh... "gedoe!"....

flowerp schreef op zondag 05 augustus 2007 @ 16:18:

Correctie: de back button heeft echt niks met het HUIDIGE HTTP protocol te maken.

Het heeft niets met welk transport protocol dan ook te maken.

Ik heb al een aantal mogelijk oplossingen genoemd die in het HTTP protocol de problemen met de back button zouden kunnen verbeteren, waaronder een sequence nummer, zodat de server weet of een click vanuit de huidige pagina komt, of vanaf een pagina die is bereikt via de back button.

Een andere mogelijkheid is het doorgeven van het gebruik van de back button, als de server hierom gevraagd heeft.

Als ik in Eclipse de back button gebruik dan -weet- mijn code dat ogenblikkelijk en kan ik diverse acties ondernemen. Het HTTP protocol heeft hier geen support voor. Met Javascript kan je soms er om heen werken, maaruh... "gedoe!"....

De server hoeft helemaal niet te weten of er een back button gebruikt is. Je vraagt een of ander document op, de server zorgt dat je dat krijgt. Als je specifieke informatie mee wilt geven, kun je dat bijvoorbeeld doen via een cookie, of via een query string. Of hoe je dat maar wilt doen. Dat is aan de client. Die kan makkelijk even een cookie meesturen als iemand op een back button heeft geklikt.

Er zijn mogelijkheden genoeg, maar omdat de huidige clients nou niet echt intelligente oplossingen voor dat soort gebruik van applicaties hebben is geen fout van het protocol. Meer van de omgeving waarin de webapplicatie draait. Maar browsers laten het voor zover ik weet niet toe om events te koppelen aan klikken op dergelijke navigatieknoppen. Als dat zou kunnen, was er geen enkel probleem. Wellicht dat het wel kan als je met ActiveX componenten of applets aan de gang gaat. Dat weet ik niet eigenlijk.

Verwijderd schreef op zondag 05 augustus 2007 @ 16:29:
[...]

Het heeft niets met welk transport protocol dan ook te maken.

[...]

De server hoeft helemaal niet te weten of er een back button gebruikt is. Je vraagt een of ander document op, de server zorgt dat je dat krijgt. Als je specifieke informatie mee wilt geven, kun je dat bijvoorbeeld doen via een cookie, of via een query string. Of hoe je dat maar wilt doen. Dat is aan de client. Die kan makkelijk even een cookie meesturen als iemand op een back button heeft geklikt.

Er zijn mogelijkheden genoeg, maar omdat de huidige clients nou niet echt intelligente oplossingen voor dat soort gebruik van applicaties hebben is geen fout van het protocol. Meer van de omgeving waarin de webapplicatie draait. Maar browsers laten het voor zover ik weet niet toe om events te koppelen aan klikken op dergelijke navigatieknoppen. Als dat zou kunnen, was er geen enkel probleem. Wellicht dat het wel kan als je met ActiveX componenten of applets aan de gang gaat. Dat weet ik niet eigenlijk.

De server hoeft ook niet op de hoogte gebracht te worden van een back actie van de gebruiker. Als je de URL verandert, zoals door een http://www.mijnURL.nl/#tellerVariabele en steeds de teller ophoogt, wordt bij een back actie de vorige pagina hersteld uit de browser cache. Overigens is dit volgens mij niet echt een waterdichte oplossing, maar goed.

Dat is mijn probleem met dergelijke client side oplossingen. Telkens als je denkt een goede oplossing te hebben, blijk je er weer op een andere manier onderuit te kunnen, bijv door andere browserinstellingen.

Verwijderd schreef op zondag 05 augustus 2007 @ 16:29:
[...]
Het heeft niets met welk transport protocol dan ook te maken.

HTTP is geen transport protocol maar een transfer protocol. Een transfer protocol zit bovenop een transport protocol (zoals TCP, of UDP), en bepaalt hoe -informatie- tussen hosts uitgewisseld wordt. Een ander voorbeeld van een transfer protocol is bijvoorbeeld JRMP.

De server hoeft helemaal niet te weten of er een back button gebruikt is. Je vraagt een of ander document op, de server zorgt dat je dat krijgt.

-zucht- we hebben het hier niet over documenten, maar over applicaties.

Ik snap dat het verschil moeilijk is om te begrijpen, maar dat is nu exact waar deze discussie nu over gaat. HTTP is oorspronkelijk bedoeld om inderdaad (hypertext) documenten mee over te dragen. De industrie heeft ons gedwongen om er ook applicaties boven op te bouwen en DAARVOOR missen er een aantal simpele maar essentiële elementen in het protocol.

flowerp schreef op zondag 05 augustus 2007 @ 16:56:

HTTP is geen transport protocol maar een transfer protocol. Een transfer protocol zit bovenop een transport protocol (zoals TCP, of UDP), en bepaalt hoe -informatie- tussen hosts uitgewisseld wordt. Een ander voorbeeld van een transfer protocol is bijvoorbeeld JRMP.

Achja, ga even in op een kleine doch niet catastrofale verspreking. Het moge duidelijk zijn dat HTTP gebruikt wordt om gegevens te transferren/transporteren/vervoeren/verzenden/hoe-je-het-ook-wilt-noemen.

-zucht- we hebben het hier niet over documenten, maar over applicaties.

In de meeste gevallen worden die als document geserveerd aan de client, maar ok, het zij niet altijd complete documenten, een stuk van een of andere stream kan natuurlijk ook.

Ik snap dat het verschil moeilijk is om te begrijpen, maar dat is nu exact waar deze discussie nu over gaat. HTTP is oorspronkelijk bedoeld om inderdaad (hypertext) documenten mee over te dragen. De industrie heeft ons gedwongen om er ook applicaties boven op te bouwen en DAARVOOR missen er een aantal simpele maar essentiële elementen in het protocol.

En ik probeer uit te leggen dat dat niets met het protocol te maken heeft, maar dat dat alles te maken heeft met de clients. Het is in theorie prima mogelijk om een applicatie te schrijven die zijn eigen user interface definieert, en die van de user agent buiten beschouwing laat. De user agent zou dan bijvoorbeeld eerst goedkeuring van de eindgebruiker moeten vragen om dat toe te laten. Vanaf dat moment zou je de functie van een back button zelf kunnen definiëren. Waarom zou er dan iets aan het HTTP protocol moeten worden gewijzigd of toegevoegd? Ik denk dat je echt een verkeerd beeld hebt van het protocol.

Ik zie hier een discussie over backbuttons, die compleet voorbij gaat aan het feit dat het botgezegd RUK is dat een webapp in een browser draait met zijn eigen UI, en dat een backbutton je hele webapp nogal in de knoei kan laten gooien. Niet eens vanuit een development-perspectief - als gebruiker vind ik het ook rete-irritant dat als ik per ongeluk op de backbutton druk (ja er zit er een op m'n muis, strontvervelend als ik met mijn hand van toetsenbord naar muis beweeg om mijn post te posten, en daarbij per ongeluk met mijn duim tegen die knop aanstoot), de hele interne state van de webapp ineens compleet lost is.

En dan terug naar het development-perspectief: tegen dit soort situaties kun je je dan wel weer indekken door regelmatig een status-update terug te sturen naar de server, of relevante data in cookies op te gaan zitten slaan, of wat er verder ook mogelijk is, maar feit blijft dat je je wederom in rare bochten moet wringen.

Wat ik persoonlijk liever zie is een gestandaardizeerde UI container die de HTML kan laten zien zoals een browser, maar waar user-interactie beter is geregeld en afgeschermd. Een backbutton is dan prima als je gewoon zelf voor een implementatie van die knop kan zorgen.

[ Voor 32% gewijzigd door .oisyn op 05-08-2007 18:58 ]

.oisyn schreef op zondag 05 augustus 2007 @ 18:54:

Wat ik persoonlijk liever zie is een gestandaardizeerde UI container die de HTML kan laten zien zoals een browser, maar waar user-interactie beter is geregeld en afgeschermd. Een backbutton is dan prima als je gewoon zelf voor een implementatie van die knop kan zorgen.

Dat ben ik volledig met je eens, maar dan is het nog steeds een issue van de user agent, en niet van het HTTP protocol. Ik denk trouwens dat je een soort XUL applicaties bedoelt of iets dergelijks?