Comet solution

Ciao a tutti, sto percando di implementare una soluzione comet per
un’applicazione fatto in Rails. Per chi non lo sapesse comet permette
l’invio di dati dal server al browser, anziché viceversa, permettendo
l’aggiornamento di più client in contemporanea, senza fare refresh.

Ora tra le varie soluzioni per Rails su cui mi sono soffermato di più

La prima però l’ho scartata (nonostante sia molto completa) perché si basa
unicamente su Flash, e quindi sono stato costretto ad eliminarla. Per
quanto
riguarda Shooting Star invece, sembra una buona soluzione (non vincolata
a
nessun plugin), ma la documentazione non è il massimo ed seguendo il
tutoria
messo a disposizione
quihttp://shooting-star.rubyforge.org/wiki/wiki.pl?Making_A_Chat_System_Within_5_Minutesnon
sto avendo grandi risultati usando Rails 2.1.

Volevo quindi chiedervi che cosa mi consigliate e se avete qualche
dritta,
link da darmi, o esperienze personali.

Thanks.

On Wed, Sep 17, 2008 at 2:43 PM, Andrea R.
[email protected]wrote:

riguarda Shooting Star invece, sembra una buona soluzione (non vincolata a
nessun plugin), ma la documentazione non è il massimo ed seguendo il tutoria
messo a disposizione quihttp://shooting-star.rubyforge.org/wiki/wiki.pl?Making_A_Chat_System_Within_5_Minutesnon sto avendo grandi risultati usando Rails 2.1.

Volevo quindi chiedervi che cosa mi consigliate e se avete qualche dritta,
link da darmi, o esperienze personali.

Thanks.

Andrea R.

Alla fine sono riuscito ad utilizzare Shooting Star che sembra
funzionare
abbastanza bene.

Per chi fosse curioso stamattina mi son trovato anche un
articolohttp://ajaxian.com/archives/comet-and-highly-interactive-websites-joe-walker-media-ajaxdove
vengono spiegate 7 tecniche per implementare una soluzione Comet. Per
qualcuno che ho sentito ieri faccio notare che 6 di queste tecniche non
usano flash :smiley:

A presto!

Andrea R., http://mikamai.com
Writing http://sensejs.wordpress.com/
Collaborating http://therubymine.it
Reading http://stacktrace.it

Andrea R. wrote:

Per chi fosse curioso stamattina mi son trovato anche un
articolohttp://ajaxian.com/archives/comet-and-highly-interactive-websites-joe-walker-media-ajaxdove

Ho letto velocemente l’articolo, le soluzioni proposte non mi convincono
molto perché hanno tutte problemi di leak. Escludendo l’uso di ActiveX a
priori (perché non cross-browser), le altre sono basate su XHR, il che
significa “pseudo-realtime”.

La soluzione migliore, al momento sembrerebbe “purtroppo” flash, e
quindi juggernaut, il quale apre un socket tra client e server, tramite
il quale la comunicazione avviene in tempo reale.

Il web (ahimé) non è nato per queste cose… Resta da approfondire
l’argomento WebSockets (HTML 5).

PS: ho trovato un blog dedicato all’argomento: http://cometdaily.com/

Ciao,
Luca.

poll != push

:slight_smile:

Il long polling è una tecnica che simula il push, ma non lo
è.PS: Paolo, complimenti per il sito. :smiley:

Nel mio SkipperMania è da un
anno che uso il long polling senza particolari problemi. Non capisco
quello che nell’articolo intendono con uso del chunked mode:
semplicemente il browser fa una richiesta XHR al server, che non
risponde finché ha dati per il client o sono passati 30 secondi. Quando
il browser ha la risposta la elabora e fa un’altra richiesta. 30 secondi
è dentro i limiti del timeout di browser e proxy così non c’è bisogno di
tecniche particolari.

Lato server queste richieste sono gestite da un Jetty 6.1 per non
appesantire Rails. La scelta di Jetty è determinata dalla presenza di un
meccanismo chiamato Continuations con cui la stessa thread può gestire
tante richieste in attesa di risposta.

Per coincidenza proprio ieri pomeriggio parlavo con uno che mi
raccontava che anni fa aveva implementato il server push con i mime
multipart. Sarà la settimana del push :slight_smile:

discussione interessante

On Thu, Sep 18, 2008 at 1:31 PM, Luca G. [email protected]
wrote:

poll != push

http != push

:slight_smile:

cioe’ se non si usano strumenti (flash, applet java) che possono
aprire socket (piu o meno) liberamente il push e’ comunque “simulato”.

PS: Paolo, complimenti per il sito. :smiley:
mi unisco ai complimenti!

Luca

P.S. L’origine di parecchie idee che sono dietro a comet & co. si puo
trovare nei lavori di Adam Rifkin e Rohit Kahre:
http://ifindkarma.com/attic/isen/ (e in quel poco che rimane in giro
di KnowNow e mod_pubsub ).

Luca M. wrote:

http != push
Esatto.

Andrea, come mai non vuoi/puoi usare flash?

Andrea, come mai non vuoi/puoi usare flash?

Allora, diciamo che voglio utilizzare una soluzione che permetta di
avere
una soluzione Comet senza vincoli tecnologici. Flash, per quanto sia
diffuso
in moltissimi browser non li copre tutti (mi sembra sia sul 95%), o
meglio
non copre l’IPhone… Questo è stato sufficente per dover cercare strade
alternative, visto la necessità di coprirlo.

Mi sono informato anche sui Web Socket a suo tempo, e a quanto si dice
promettono bene, ma prima di vederli implementati su tutti i browser ci
vorrà qualche anno. Orbited http://orbited.org/ ne offre una
implementazione già utilizzabile, ma avevano alcune limitazioni nel mio
caso
di utilizzo. Sempre Orbited era una soluzione più che valida, si integra con
Rails, ma la documentazione a riguardo è outdated, quindi per adesso
cercavo
qualcosa più ‘sicuro’ e Rails oriented.

Alla fine mi sono diretto su Shooting Star, che lavora con druby, e che
utilizza flash se presente, ma usa XHR (e quindi un pseudo realtime)
negli
altri casi. Mi sembra quindi una buona soluzione che usa la tecnologia
migliore se la trova, e qualche trucchetto in caso contrario :). Presto
vorrei fare un bel tutorial, anche perchè secondo me è un argomento
piuttosto interessante.

Ciao a tutti!

Immaginavo fosse a causa dell’iPhone. :wink:
Sinceramente non capisco il tuo discorso: scarti una soluzione
supportata dal 95% (?) dei browser, per accontentare una fetta di utenza
che si assesta attorno allo 0.48% (CNN Fortune Agosto 2008
http://tinyurl.com/5fkbrg).

Lo so che è figo fare una versione della propria webapp per quel device,
ma, a mio avviso, non dovrebbe pesare troppo nelle scelte
architetturali.
Puoi sempre pensare di adottare tecniche di polling AJAX per la versione
mobile, che, con la sua modesta diffusione, non dovrebbe pesare troppo
sul carico dei server.

Luca

On Fri, Sep 19, 2008 at 10:09 AM, Luca G. [email protected]
wrote:

sul carico dei server.

E’ meglio chiarire alcuni dettagli. Shooting Star usa flash quando lo
trova
installato, mentre implementa XHR quando non è installato. In questo modo
non scarto la soluzione supportata dal 95% dei browser, ma la integro
con
altre tecniche pseudo realtime nel momento in cui la soluzione ottimale
non
è disponibile.

Per quanto riguarda l’IPhone, concordo con la tua visione, ma va
precisato
che l’applicazione non è una tipica app. E’ un’applicazione di building
automation, dove i vari componenti dell’abitazione saranno controllati
principalmente tramite dispositivi mobili (90% dei casi) e dal solo
padrone
(o pochi altri). L’IPhone è quindi uno dei primi candidati, sia per motivi
di marketing, che di funzionalità, naturalmente senza dimenticare il
supporto a tutti gli altri device mobili.

Concludo dicendo che nel fondo l’idea è una sola, cioè quella di non essere
limitati dalle tecnologie usate. Dover avere flash installato, seppure
banale, è un limite su questa ottica.

Grazie per l’interessante discussione a tutti :slight_smile: