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.
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).
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
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.
Immaginavo fosse a causa dell’iPhone.
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
