Vi är lite fundersamma hur vi ska vidareutveckla vår sida med lite realtidsfunktioner. Idag har vi använt ren HTML (php) med auto reload och Javaapplet med socket kommunikation på en egen port. Java funkar perfekt men har nackdelarna att klienten måste ha java och många (fler och fler) brandväggar stoppar kommunikation på "okända" portar. HTML har ju fördelen att det alltid funkar och att brandväggar inte är något problem. Dock ger ju inte reload någon riktig realtidsfunktion. (se våra tävlingar "Duellen" resp. "Javaduellen" på vetgirig.nu)

Vilken teknik skulle ni välja för att utveckla t.ex. en realtids chat?!?

Kravet ska ju vara att det måste funka genom stränga brandväggar och att i princip alla webläsare ska kunna hantera det utan att behöva hämta en plug-in.

Javascript/DOM + Ajax?

Någon som har koll på hur många som inte tillåter/klarar javascript?!

Har tidigare haft en del inmatningskontroller i javaskript (giltig e-postadress etc) men har ändå fått in adresser som inte följer reglerna. Antar att det beror på att vissa helt enkelt skippar javascript...?!!

litet sidospår från huvudfrågan...

Jag skulle använda javascript(ajax <-- Modeord) och sedan "polla" ett script på servern t.ex. en gång per sekund för att uppdaterad information. Det är ju inte äkta realtid där servern skickar information direkt till klienten när den dykter upp men nära nog anser jag.

Edit: Jag tror siffrar på javascript enabled ligger runt 95% om man räknar bort bottar från sin statistik.

1) Aldrig ha inmatningskontroller som enbart gäller för klient-sidan.

2) W3Schools.com uppmätte i Januari 2006 att 10% av deras besökare hade javascript avstängt.

3) Förlita dig inte på statistik annat än för din egen sajt. Man kan alltid förutsätta saker och ting om målgruppen, men det gör det inte sant.

Och som svar på ursprungliga frågan, är jag ensam om att tycka att Flash hade gjort sig bra för realtidslösningar? Flash kan göras tillgängligt, det är snabbt, i många fall snabbare än AJAX, man kan kräma in lite fin vektorgrafik utan att det tynger ner, och det har en stor spridning.

I couldn't agree more. Mycket bra skriver Kaffe.

Flash är helt klart en bra teknik, dock kan jag inte flash så jag skulle fortfarande välja ajax :P
Normalt är att ca 10% av besökarna har javascript disabled men om man räknar bort bottar så tror jag det hamnar runt 5-6%. Men som du säger så bör man mäta själv på sin målgrupp, jag tror nog att andelen som tillåter javascript kan vara högre hos er än hos väl medvetna datormänniskor som besöker W3C.

Nu för tiden har väl Flash t.o.m. stöd för PUSH? Lite dumt att ligga och polla varje sekund, det kan lasta en server ganska bra.

Http-tunneling på port 80 funkar ganska bra också, har jag använt en del tidigare.

Får man fråga varför ni tror att det är fler som har stöd för flash än för javascript? Det låter lite konstigt i mina öron. Hursomhelst så om flash stödjer någon form av PUSH-teknik så är det såklart bättre, men problemen med firewalls osv kvarstår då antar jag, såvida man inte kan köra den via port 80. Ajax fungerar ju utan problem för alla som har javascript påslaget (och det är ju rätt enkelt att visa för en användare att "<noscript>Hej, slå på javascript</noscript>"). Det går ju dessutom att koda hyfsat med fallback och använda statisk kod för att reloada en iframe med begränsad funktionalitet om man är en riktigt hårdför standardista.

Jag antar (som grazzy påpekar) att PUSH kommer att tvärstanna i brandväggarna (för väldigt många).

Trodde inte flash var särskilt bra på kommunikation, men där är jag tydligen fel ute?! (har bara sett det som en ren klient-grafik-grej...)

Är även rädd att http-tunneling kommer vara mer och mer problematiskt när säkerheten skruvas åt och allt granskas av en proxy (i alla fall på företagen...)

Låter som javascript/ajax är modellen!?? Någon som har några bra länkar/exempel i ämnet (dvs i det syfte som vi har - realtids kommunikation mellan klient-server) som starthjälp??

Flash kombinerat med Flash Communication Server stödjer PUSH.
FCS är dock riktigt dyr, men det finns alternativ som tex Red 5 som är open source.

Då det gäller andelen användare som har javascript och Flash aktivt så är Flash aningen mer utbrett.
thecounter.com har statistik från en bred användarbas då det gäller javascript och för tillfället är det 93% som har 1.2+
Enligt NPD Online hade i april runt 97% Flash 6 eller högre version.
Självfallet så skiljer det en hel del beroende på målgrupp vad de verkliga siffrorna blir för dina besökare.

FCS har implementerat http tunneling:
http://www.adobe.com/devnet/flashcom/artic...alls_proxy.html

Sen är väl frågan också.. om man nu verkligen vill.. vill vill vill så skulle man ju kunna koda en säg, java eller perl-deamon som lyssnar på ett eget ip på port 80 och där man inte stänger anslutningen utan kontinuerligt pushar ut data? Då borde denna data gå att läsa med javascript/xml-objekt... inte riktigt säker på detta tyvärr.

[QUOTE=Conth,Aug 14 2006, 15:44]Modellen är att använda Http-tunneling, och om nån proxy stoppar det gå över till att polla på de klienterna. Det är mest de som sitter på säkra nät (tex banker och dyl) som inte klarar att använda en tunnlad klient.

Jo absolut. Dock behöver du ju fortfarande se till att klienten då poll:ar direkt efter att du "push:at" ut data. Vet inte om risken finns att någon proxy/brandvägg "klipper" förbindelsen innan vi hinner pusha ut data om vi "håller" på svaret på serversidan!?

Serversidan ser jag inte som ett problem - det är bara ;) att fixa. På servern har man ju full koll själv (förhoppningsvis).

Klientsidan är mer problematisk med olika browsers, plug-ins, brandväggar etc

Du kan läsa mer här.

//Björn

Min tanke var att ha ett asyncron xml-objekt som hela tiden läser. Det är ett event i objektet som säger till om det kommit mera data. Vet dock bara inte riktigt hur det funkar att läsa datat i objektet innan http-anropet är avslutat. Jag misstänker att det går eftersom man enkelt kan avläsa status (1-5) i ajax-anrop.

Titta tex på hur prototype hanterar ajax, det är där enkelt att lägga till callback-funktioner som gör saker baserat på events.

Jag har för mig att detta fungerar om du använder Microsofts COM-objekt direkt (alltså tex i ett program), men du kan inte läsa detta via JavaScript i browsern.

Kanske irrelevant för denna frågan, men tål att nämnas iom att Flash tidigare också nämnts i tråden.

Nya Flashspelaren stödjer socketkommunikation och man kan därför skapa en klient som ansluter till en IRC-server.

Problemet ligger i restrektiva brandväggar och den policyfil som måste användas. Leder i slutänden till att man får köra egen IRC-server på port 80, men då löser man ändå inte helt problemet med brandväggarna (packet inspection). .. om ingen annan kan/har luskat sig fram till en bättre lösning? :)

Att använda HTTP-streaming (Comet) funkar nog bra för en "mindre" chat, men som nämns så finns det problem med prestanda när många klienter är anslutna.

[EDIT]

O, hade ju helt glömt bort mitt egna lilla experiment med XHR :o .. kika på sandbox.particle-dreams.net/chat/index.php med tillhörande .phps för källkod. Använder Sajax för kommunikation (vilket jag inte idag skulle använda)

Länken som b_andersson postade visar hur man kan använda javascript/xml för den här typen av kommunikation. Det är lite bökigt, men det skall nog funka. Självklart så är säkert flash stabilare om man kör det mot en irc-server på port 80 som ejot säger. Det krävs ruggigt mkt kod (och erfarenhet) för att producera stabila större ajax-applikationer just nu.

I jakten på fåniga namn så har man döpt tekniken till Comet. Hur fånigt det än är så har termen fastnat bland många "ledare" inom ajax-världen.

En bra artikel på ajaxian.com med information och bra länkar finns här: http://www.ajaxian.com/archives/come...x-applications

Wikipedia har naturligtvis lite om ämnet:
http://en.wikipedia.org/wiki/Comet_(programming)

Det man ska tänka på är att webbservern för den här typen av tillämpningar bör konfigureras för att klara den lite speciella situationen. Ligger man på ett webbhotell som använder Apache 1.3-serien med många kunder på en server kan det gå ganska fort att använda upp alla tillgängliga servrar... det är något att tänka på beroende på vilken typ av tillämpning man bygger. 1000 samtidiga användare kommer kräva en del som kanske traditionella webbservrar inte riktigt är byggda för.