Creare una chat

[Ospite monsterflying]

Ciao a tutti, vorrei chiedervi un consiglio su cosa usare per ottenere:

registrazione da database (quindi chi si registra sul sito può direttamente loggarsi nella chat, senza doversi registrare di nuovo), stanze multiple, elenco utenti connessi (possibilmente con indicazione della stanza in cui sono loggati), creazione moderatori, kick & ban, creazione automatica log (ovvero tutto ciò che c'è in chat pubblica viene registrato su un file), messaggi privati, messaggi di azione (che compaiono scritti in corsivo, con formato "TIZIO sta facendo qualcosa") e possibilità di passare da una stanza all'altra senza doversi riloggare.

Non ho particolari pretese grafiche, semplicemente vorrei evitare i banner.

Grazie a chi mi saprà aiutare, vi aspetta una statua virtuale.

[Ospite jbrozz]

PHP e MySQL ... da far girare su un fantastico server apache linux

[grigio60]

PHP e MySQL ... da far girare su un fantastico server apache linux

e applet Java per la parte interattiva lato utente

[squall_84]

oppure vuoi tutto già pronto e subito?

[Ospite monsterflying]

oppure vuoi tutto già pronto e subito?

Fosse già pronto mica sarebbe male...

[squall_84]

se non ti importa della pubblicità ci sono siti che offrono chat gratuite da inserire nel proprio sito.

Alcune sono ben fatte, ma hanno la pubblicità che disturba.

Se poi tu devi fare un lavoro professionale, ovviamente è meglio che te la programmi da solo.

[Ospite jbrozz]

e applet Java per la parte interattiva lato utente

che schifezza... evita tutto cio che è java...

Java == pesantezza

per fare il lato client usa semplicemente AJAX

[grigio60]

che schifezza... evita tutto cio che è java...

Java == pesantezza

per fare il lato client usa semplicemente AJAX

Beh definire Java una "schifezza" con tutti gli sviluppi multipiattaforma basati su di esso....

Vallo a dire a chi usa Eclipse o Aptana che "Java è una schifezza"

AJAX non va bene, non ancora per lo meno, per una chat web-based: ci sono dei problemi di compatibilità multipiattaforma per cui rischi di andare incontro a utenti che non sono in grado di accedere alla chat o di chattare correttamente sulla base del browser che usano. Se poi hanno impostato le preferenze per Javascript in modo da disabilitare certe funzionalità, sono ancora fritti.

Inoltre Java è vero che richiede qualche risorsa locale in più ma garantisce anche una migliore interazione e sincronizzazione col server, soprattutto in presenza di grossi volumi di traffico e di un'elevata quantità di utenti. Con AJAX invece tutto è sulle spalle del server con conseguenti problemi di congestione. E non è un caso che webchat basate su AJAX in giro ce ne siano molto poche mentre la quasi totalità si basa su Java.

Piano quindi coi giudizi, te la do buona solo perché hai vent'anni e l'irruenza della gioventù, ma la prossima volta rifletti bene su quel che vuoi dire

[redvex]

Beh definire Java una "schifezza" con tutti gli sviluppi multipiattaforma basati su di esso....

Vallo a dire a chi usa Eclipse o Aptana che "Java è una schifezza"

AJAX non va bene, non ancora per lo meno, per una chat web-based: ci sono dei problemi di compatibilità multipiattaforma per cui rischi di andare incontro a utenti che non sono in grado di accedere alla chat o di chattare correttamente sulla base del browser che usano. Se poi hanno impostato le preferenze per Javascript in modo da disabilitare certe funzionalità, sono ancora fritti.

Inoltre Java è vero che richiede qualche risorsa locale in più ma garantisce anche una migliore interazione e sincronizzazione col server, soprattutto in presenza di grossi volumi di traffico e di un'elevata quantità di utenti. Con AJAX invece tutto è sulle spalle del server con conseguenti problemi di congestione. E non è un caso che webchat basate su AJAX in giro ce ne siano molto poche mentre la quasi totalità si basa su Java.

Piano quindi coi giudizi, te la do buona solo perché hai vent'anni e l'irruenza della gioventù, ma la prossima volta rifletti bene su quel che vuoi dire

Permettimi di dissentire

1) Allo stato attuale delle cose ci sono solo 2 metodi per fare una richiesta ajax, ovvero un per i Browser (la B maiuscola non è un caso ) e uno per Internet Exploder , tramite eccezioni si può gestire un oggetto httprequest senza problemi di sorta.

2) E' vero che tutto è sulle spalle del server, ma è anche vero che puoi creare un "service" leggerissimo che ti permetta di non appesantire il server e di gestire tutto con una certa facilità, l'xml esiste appunto per questo!

3) Ajax, se lo si sa usare correttamente, è una manna dal cielo per tutto il web, non a caso il cosiddetto Web 2.0, che molti confondono con youtube e le comunity online è nato e poggia le sue fondamenta proprio su ajax.

4) Per il JS bloccato... secondo hai più possibilità di avere java bloccato, JS è usato ovunque, dalle semplici pagine DHTML alle più complesse applicazioni Ajax, persino per aprire popup o caricare sliti dinamicamente.

5) Java, vuoi o non vuoi, è il passato, anche se ha dato molte soddisfazioni a chi l'ha usato, ma se qualcuno mi chiedesse oggi: "Cosa devo imparare per fare il webmaster", di certo non gli suggerirei Java!

@Brozz87, se fai questo mestiere, o lo vuoi fare in seguito continua con Ajax è il presente e con buone probabilità anche il futuro prossimo (sul futuro non possiamo dire nulla )

@grigio60, lo stesso discorso che tu hai fatto a brozz potrei farlo anche io a te... non essere affrettato a dare giudizi

PS. Naturalmente i miei discorsi su java valgono, se rapportati alle web-application, Eclipse e Aptana sono desktop-application e li il discorso è diverso, anche se non si può in ogni caso paragonare in termini puramente velocistici un'applicazione scritta in C++ o Object-C, solo per fare 2 esempi, con una in Java, anche se con buona probabilità solo quest'ultima sarà multipiattaforma.

[grigio60]

Permettimi di dissentire

1) Allo stato attuale delle cose ci sono solo 2 metodi per fare una richiesta ajax, ovvero un per i Browser (la B maiuscola non è un caso ) e uno per Internet Exploder , tramite eccezioni si può gestire un oggetto httprequest senza problemi di sorta.

allora, chiariamo un paio di cosucce:

1) non sto dicendo che AJAX non va bene in generale: qua si sta parlando di un'applicazione web specifica, ossia una "chat room" multiutente. Io sto valutando AJAX vs. Java per "questa" specifica applicazione. Per il resto, son pienamente convinto che AJAX sia una tecnologia vincente e da sfruttare al massimo, ma questo non la rende automaticamente "la migliore" per qualsiasi applicazione web. Penso che questo punto sia fondamentale da chiarire per comprendere meglio la mia posizione.

2) vero che XMLHttpRequest ha due varianti, IE e resto del mondo. ma è anche vero che la "J" del nome, AJAX, unita all'oggetto in questione presenta ancora dei problemi. ci sono pagine web 2.0 basate su AJAX che purtroppo per un motivo o per un altro NON funzionano su tutti i browser. ho degli esempi di pagine che funzionano ottimamente sotto firefox, opera e ie, su entrambe le piattaforme mac e win per i primi due, ma non vanno su safari. altre che funzionano benissimo solo con firefox e ie, ma non con gli altri browser. altre ancora che funzionano bene con firefox ma meno bene con ie o viceversa. in molti casi, se non quasi sempre, dipende da chi ha sviluppato il codice, che non ha fatto un lavoro completamente compatibile, ma in altri dipende purtroppo proprio dal browser stesso. io ho una piccolissima applicazione AJAX che usa un "onLoad" per stabilire il browser: ebbene, questa applicazione NON gira su Safari perché si blocca sull'onLoad, togliendolo funziona. questo per dire che AJAX comunque, proprio per la sua gioventù, presenta ancora problemi di stabilizzazione (che saranno risolti spero)

3) il caso specifico della chat: AJAX per sua natura è ottimo per le interazioni dirette utente-server: l'utente manda una richiesta, il server risponde, il risultato viene presentato nella stessa pagina della richiesta senza ulteriori operazioni da parte dell'utente. ma una chat multiutente (non un forum) richiede un meccanismo più complesso, per cui il server può (e anzi normalmente lo fa) rispondere in assenza di qualsiasi richiesta da parte dell'utente perché sta rispondendo a una richiesta di un altro utente. in altri termini: io vedo sulla mia pagina il risultato di operazioni eseguite da un altro cliente questo può accadere anche prima che io abbia emesso una singola richiesta verso il server.

Questo meccanismo è molto diverso da quello di AJAX, che per sua natura supporta benissimo transazioni di tipo puntuale: qua invece si tratta di far arrivare a tutti i client collegati la stessa informazione contemporaneamente e in modo indipendente dal fatto se il singolo utente ha inviato o meno una richiesta di interazione. Il server gestisce una richiesta AJAX come se fosse una normale richiesta di una pagina web, ossia come una transazione punto-punto con il singolo client; per gestire una chat il server invece deve gestire una transazione punto-multipunto, inviando la risposta non solo al client richiedente ma anche a tutti gli altri client in quel momento collegati con quella pagina. E per far questo allo stato attuale la tecnologia AJAX ancora non è sufficiente e bisogna ricorrere a tecnologie più sofisticate, come Java, appunto, dove l'interazione tra i client e i server si basa su un meccanismo più complesso di una semplice transazione HTTP.

Come vedi, non ho dato affatto un "giudizio affrettato" - né tantomeno ho parlato di "schifezze" in modo assolutamente gratuito e superficiale

P.S. so benissimo che è possibile implementare delle chat room in AJAX ma allo stato dell'arte attuale il problema legato a quanto detto sopra è il supporto del carico - gli esempi di chat room AJAX che ho visto in giro finora supportano pochi utenti per chatroom, poi il server tende a "sedersi" (ogni interazione verso i client comporta un picco per il server).

[Ospite monsterflying]

Grazie a tutti per gli utili consigli:fiorellino:

[redvex]

vero che XMLHttpRequest ha due varianti, IE e resto del mondo. ma è anche vero che la "J" del nome, AJAX, unita all'oggetto in questione presenta ancora dei problemi. ci sono pagine web 2.0 basate su AJAX che purtroppo per un motivo o per un altro NON funzionano su tutti i browser. ho degli esempi di pagine che funzionano ottimamente sotto firefox, opera e ie, su entrambe le piattaforme mac e win per i primi due, ma non vanno su safari. altre che funzionano benissimo solo con firefox e ie, ma non con gli altri browser. altre ancora che funzionano bene con firefox ma meno bene con ie o viceversa. in molti casi, se non quasi sempre, dipende da chi ha sviluppato il codice, che non ha fatto un lavoro completamente compatibile, ma in altri dipende purtroppo proprio dal browser stesso.

per esperienza personale il 95% dei casi di incompatibilità e forse più sono identificabili a priori, basta conoscere gli standard (Safari e Opera funzioneranno sicuramente), e le limitazioni di IE e FF. La maggior parte dei casi si tratta di iterazioni con il DOM o di cambio di proprietà css aggirabili in altro modo. Rimane un 5% di casistica inesplorato, ma con un pò d'impegno si riesce a rendere tutto multibrowser. Te lo dico per esperienza... per lavoro ho sviluppato un'applicazione business web based, incentrata completamente su ajax, ci lavoro da un anno buono e finalmente ha raggiunto lo stadio di "final"

il caso specifico della chat: AJAX per sua natura è ottimo per le interazioni dirette utente-server: l'utente manda una richiesta, il server risponde, il risultato viene presentato nella stessa pagina della richiesta senza ulteriori operazioni da parte dell'utente. ma una chat multiutente (non un forum) richiede un meccanismo più complesso, per cui il server può (e anzi normalmente lo fa) rispondere in assenza di qualsiasi richiesta da parte dell'utente perché sta rispondendo a una richiesta di un altro utente. in altri termini: io vedo sulla mia pagina il risultato di operazioni eseguite da un altro cliente questo può accadere anche prima che io abbia emesso una singola richiesta verso il server.

A parte che secondo me il nostro amico cercava un url da dove scaricare una chat bella e fatta e noi siam partiti per la tangente, ma il confronto è comunque interessante!

Il problema secondo me qui è di approccio, giustamente tu mi dici che le comunicazioni debbano essere sincronizzate tra gli utenti e che il server debba rispondere 1-N.

La mia idea è leggermente diversa e l'approccio forse "semplificato", ma sono abituato a pensare in questo modo.

Vedo la chat come un'iterazione continua tra client e server. Ogni richiesta del client (messaggio) viene inviata al server che in maniera asincrona scrive il file xml del "log" orario o giornaliero o come vuoi te. Questo log viene rispedito al client ad intervalli regolari, anche molto piccoli (il file in questione è decisamente piccolo essendo un xml di puro testo), in questo modo la sincronia dei messaggi è garantita dal server e non dai client, mentre il lag è abbastanza contenuto (e predeterminato). In questo caso il numero di utenti è ininfluente perchè è come se il singolo utente chattasse non con altri X utenti, ma direttamente con il server.

Come vedi, non ho dato affatto un "giudizio affrettato" - né tantomeno ho parlato di "schifezze" in modo assolutamente gratuito e superficiale

Pardon, non volevo offenderti