View Full Version : Creazione di una chat Client/Server
eriksingh15
25-02-2014, 19:58
Salve a tutti,
vorrei creare un programma di chat in C# ben fatto, che dopo ho intenzione di ampliare incorporando funzionalità di chiamate voip (solo tra pc), ma ho molti dubbi su come la chat debba essere gestita, sopratutto a livello di client/server e le loro rispettive funzioni.
Potete darmi delle delucidazioni al riguardo, dandomi un'idea sull'argomento?
Grazie a tutti :)
Daniels118
26-02-2014, 07:29
Prima di tutto cercherei di capire bene che tipo di chat vuoi realizzare.
Ad esempio al momento mi vengono in mente questi tipi:
1) stanza - un luogo comune dove possono entrare diverse persone;
2) 1vs1 - si seleziona un interlocutore da un elenco;
3) gestita - come la stanza, ma c'è una persona che decide chi far parlare.
Poi ci sono altri aspetti, come la necessità di registrazione, la possibilità di vedere tutti gli utenti o solo quelli selezionati come amici e chi più ne ha più ne metta.
starfred
26-02-2014, 20:40
Ciao, il cuore di tutto è la progettazione.
Se, come ipotizzo, hai tempo a disposizione e non hai nessun cliente che ti assilla fai un bel modello a cascata (nei tempi attuali un po' vetusto ma secondo me è un ottimo chiarificatore) del tuo progetto che vuoi realizzare.
Ricorda sempre che il linguaggio di programmazione è solo uno strumento lo spartito musicale è la progettazione :D
eriksingh15
26-02-2014, 21:46
Grazie per le risposte.
Vorrei proprio realizzare una chat dove un utente può registrarsi e avere più contatti, che poi può vedere quando essi vengono online.
Però ho le idee molto confuse al riguardo.
Sono riuscito a realizzare una chat di una persona che comunica con un'altra, ma è molto semplice e non prevede l'uso di un server, ma i messaggi vanno direttamente da un pc all'altro (funziona solo nel locale).
E quindi non mi è neanche tanto chiara la funzione del server. Qualcuno può spiegarmi? Grazie :mc:
se per un momento decidessi di abbandonare c# in favore di un approccio più moderno (e per certi aspetti migliore) ti suggerirei:
- websocket per la parte chat, puoi implementare una chat in realtime con uno sforzo "minimo".
- webrtc per la parte voip
linguaggio utilizzato javascript sia lato client che server (node.js).
...oppure il linguaggio Opa, con tanto di esempio già fatto
https://github.com/MLstate/opalang/wiki/Hello,-chat
...oppure il linguaggio Opa, con tanto di esempio già fatto
https://github.com/MLstate/opalang/wiki/Hello,-chat
a quel punto meglio Meteor
https://www.meteor.com/
ma credo sia troppo "in la" per il thread starter
tomminno
27-02-2014, 10:49
se per un momento decidessi di abbandonare c# in favore di un approccio più moderno (e per certi aspetti migliore) ti suggerirei:
- websocket per la parte chat, puoi implementare una chat in realtime con uno sforzo "minimo".
- webrtc per la parte voip
linguaggio utilizzato javascript sia lato client che server (node.js).
In cosa Javascript (e l'utilizzo forzato di un browser) potrebbe essere migliore di un linguaggio come C# (ma poteva essere pure Java)?
Per realizzare la chat e l'autenticazione dell'utente il solo Javascript non ti basta, hai bisogno di una parte server. La implementi sempre in Javascript? Quanti hosting trovi che ti possano fornire l'ambiente per far girare node.js lato server? Come facilità di Debug come si rapportano le 2 soluzioni?
Performance?
Per la UI Javascript non ti basta hai bisogno di conoscere l'html.
Questo comporta che devi lottare con le compatibilità tra i vari browser, imparare ad usare jquery, bootstrap...
Definire più moderno e forse migliore, un approccio provato e abbandonato dai più (comunque solo per la parte di interfaccia) per enormi problemi di performance, mi pare un azzardo.
In cosa Javascript (e l'utilizzo forzato di un browser) potrebbe essere migliore di un linguaggio come C# (ma poteva essere pure Java)?
Per il fatto che scrivi in UN solo linguaggio UNA sola app che può funzionare su qualsiasi computer/smartphone/tablet/device che abbia un browser.
Solo per questo motivo ci si potrebbe fermare qui.
Per realizzare la chat e l'autenticazione dell'utente il solo Javascript non ti basta, hai bisogno di una parte server.
Si l'ho scritto nel mio post che ti serve anche lato server javascript (nodejs)
La implementi sempre in Javascript? Quanti hosting trovi che ti possano fornire l'ambiente per far girare node.js lato server?
https://www.heroku.com/
https://www.nodejitsu.com/
sono i più famosi e "immediati" nel senso che ti danno una PaaS quindi devi solo caricare la tua app per farla funzionare e non preoccuparti praticamente di nient'altro.
Come facilità di Debug come si rapportano le 2 soluzioni?
Non saprei rispondere su questo punto sinceramente.
Performance?
Sono sempre di più le big company che adottano Node, specialmente per le performance.
https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
Sono numeri che fanno impressione.
Se poi parliamo di una chat è probabilmente un ambito dove Node.js è un mostro abbinato a websockets.
Per la UI Javascript non ti basta hai bisogno di conoscere l'html.
Questo comporta che devi lottare con le compatibilità tra i vari browser, imparare ad usare jquery, bootstrap...
Seriamente nel 2014 l'html o un framework come bootstrap può essere paragonato in difficoltà a programmare in un linguaggio come C# o Java?
Mi viene un pò da ridere su questo :asd:
Definire più moderno e forse migliore, un approccio provato e abbandonato dai più (comunque solo per la parte di interfaccia) per enormi problemi di performance, mi pare un azzardo.
La realtà a me sembra totalmente diversa, tanto per fare un esempio ieri GitHub ha annunciato che stanno lavorando a un nuovo editor sviluppato totalmente in javascript e basato su node-webkit...e volendo la lista di esempi è lunghissima.
Direi quindi che quello che hai scritto è più una tua sensazione o pensiero che (per fortuna) non corrisponde alla realtà.
Porta qualche fonte a sostegno della tua idea e possiamo parlarne.
eriksingh15
27-02-2014, 14:22
Grazie per le risposte.
Io comunque conterei di fare un progetto basato sul modello client/server, e le soluzioni che mi avete proposto mi sembrano buone.
Però vorrei capire di più sulla funzione del server in una chat: a cosa serve? Ho letto che serve per l'autenticazione, e poi? Per stabilire le connessioni?
Voglio sciogliere i dubbi su questo aspetto della chat.
Grazie mille a tutti!
Daniels118
27-02-2014, 14:58
Il server gestisce i dati degli utenti e l'autenticazione. E' indispensabile che i dati si trovino su un server gestito da un terzo per evitare che gli utenti possano appropriarsi dei dati di altri utenti o falsificare la propria identità.
Poi c'è l'aspetto tecnologico.
Le attuali tecnologie standard non consentono di instaurare una connessione tra due "pari", deve esserci sempre un server ed uno o più client.
Anche volendo attribuire arbitrariamente il ruolo di server ad uno dei partecipanti si incontrerebbero notevoli difficoltà (indirizzo da contattare variabile, firewall, ecc.).
ingframin
27-02-2014, 16:18
Grazie per le risposte.
Io comunque conterei di fare un progetto basato sul modello client/server, e le soluzioni che mi avete proposto mi sembrano buone.
Però vorrei capire di più sulla funzione del server in una chat: a cosa serve? Ho letto che serve per l'autenticazione, e poi? Per stabilire le connessioni?
Voglio sciogliere i dubbi su questo aspetto della chat.
Grazie mille a tutti!
Il fatto e' che tu hai posto una domanda semplice e sono partiti i soliti super agguerriti super esperti informatici.
Il server ti serve o non ti serve in base a come strutturi la rete ad alto livello.
La chat e' come se fosse una rete a se stante (tu utente non vedi i protocolli che stanno sotto).
Quindi: 2 o piu' computer che comunicano tra loro direttamente formano una rete peer-to-peer.
Nessun server o altro in mezzo. Fantastica ma molto complessa da gestire.
Es. La chat che hai fatto tu.
Soluzione client - server:
I computer coinvolti nella chat mandano i messaggi a un server centrale che poi provvede a distribuirli ai membri della chat. Es. IRC.
La soluzione col server in mezzo, a parte tutte le menate sui dati, ti serve innanzitutto per semplificare la gestione della chat, per fare si che gli utenti possano essere facilmente a conoscenza dello stato degli altri in tempo reale senza mandare 100000000000000000000 pacchetti in rete per chiedere a tutti se ci sono o no, per facilitare lo scambio di files e per mantenere un datalog di cio' che avviene o addirittura registrare la chat.
Il server normalmente ha sopra un programma che gestisce le connessioni e una base di dati (o un sistema alternativo, ma prendiamo il db che e' il piu' semplice).
Immagina di avere utente A, utente B e il server.
Come funziona una sessione di chat?
1) A e B si autenticano col server ed entrano in chat -> Il server costruisce una tabella che rappresenta la stanza e (di solito) informa A e B che entrambi sono collegati alla "stanza"
2) A scrive un messaggio -> Il server prende il messaggio, lo salva in tabella e comunica ad A e B l'aggiornamento della tabella -> B vede il messaggio a video
3) B risponde -> Vedi punto due al contrario
e cosi' via...
Questo meccanismo fa si che i terminali di A e B siano super semplici da realizzare e tutta l'elaborazione e' fatta dal server.
La chat diretta e' invece l'analogo di una telefonata: sta a chi parla informarsi costantemente sullo stato di chi e' dall'altra parte ovvero "mantenere una connessione aperta" -> protocollo sincrono.
Se un server memorizza i messaggi la consegna non deve avvenire per forza immediatamente -> protocollo asincrono.
Spero di averti chiarito un poco le idee.
Se ti interessa un po' la teoria ti consiglio di leggere il libro di Tanenbaum "Reti di Calcolatori" oppure "Reti di Telecomunicazione" di Achille Pattavina (un poco palloso ma super completo).
Buon divertimento ;)
eriksingh15
27-02-2014, 21:05
Il fatto e' che tu hai posto una domanda semplice e sono partiti i soliti super agguerriti super esperti informatici.
Il server ti serve o non ti serve in base a come strutturi la rete ad alto livello.
La chat e' come se fosse una rete a se stante (tu utente non vedi i protocolli che stanno sotto).
Quindi: 2 o piu' computer che comunicano tra loro direttamente formano una rete peer-to-peer.
Nessun server o altro in mezzo. Fantastica ma molto complessa da gestire.
Es. La chat che hai fatto tu.
Soluzione client - server:
I computer coinvolti nella chat mandano i messaggi a un server centrale che poi provvede a distribuirli ai membri della chat. Es. IRC.
La soluzione col server in mezzo, a parte tutte le menate sui dati, ti serve innanzitutto per semplificare la gestione della chat, per fare si che gli utenti possano essere facilmente a conoscenza dello stato degli altri in tempo reale senza mandare 100000000000000000000 pacchetti in rete per chiedere a tutti se ci sono o no, per facilitare lo scambio di files e per mantenere un datalog di cio' che avviene o addirittura registrare la chat.
Il server normalmente ha sopra un programma che gestisce le connessioni e una base di dati (o un sistema alternativo, ma prendiamo il db che e' il piu' semplice).
Immagina di avere utente A, utente B e il server.
Come funziona una sessione di chat?
1) A e B si autenticano col server ed entrano in chat -> Il server costruisce una tabella che rappresenta la stanza e (di solito) informa A e B che entrambi sono collegati alla "stanza"
2) A scrive un messaggio -> Il server prende il messaggio, lo salva in tabella e comunica ad A e B l'aggiornamento della tabella -> B vede il messaggio a video
3) B risponde -> Vedi punto due al contrario
e cosi' via...
Questo meccanismo fa si che i terminali di A e B siano super semplici da realizzare e tutta l'elaborazione e' fatta dal server.
La chat diretta e' invece l'analogo di una telefonata: sta a chi parla informarsi costantemente sullo stato di chi e' dall'altra parte ovvero "mantenere una connessione aperta" -> protocollo sincrono.
Se un server memorizza i messaggi la consegna non deve avvenire per forza immediatamente -> protocollo asincrono.
Spero di averti chiarito un poco le idee.
Se ti interessa un po' la teoria ti consiglio di leggere il libro di Tanenbaum "Reti di Calcolatori" oppure "Reti di Telecomunicazione" di Achille Pattavina (un poco palloso ma super completo).
Buon divertimento ;)
Grazie mille per i chiarimenti, è più o meno come pensavo e quindi ora ho delle conferme.
Il fatto è che sono uno studente di quinta ITIS Informatico (progetto "Abacus") e vorrei iniziare questo progetto con un mio compagno di classe.
L'idea è di fare un programma di chat con un architettura client/server, e poi ampliarlo con funzionalità voip.
Ora devo capire come implementare la mia idea, visto che in partenza volevo farlo in C# ma certi utenti hanno proposto delle idee interessanti, come il websocket, che mi sembra più veloce da realizzare.
Per quanto riguarda la programmazione, da quello che ho capito la parte server sarà molto più complessa della parte client, giusto?
Ora ho dei dubbi sul fatto che il progetto sia alla mia portata :stordita:
ingframin
27-02-2014, 22:14
Grazie mille per i chiarimenti, è più o meno come pensavo e quindi ora ho delle conferme.
Il fatto è che sono uno studente di quinta ITIS Informatico (progetto "Abacus") e vorrei iniziare questo progetto con un mio compagno di classe.
L'idea è di fare un programma di chat con un architettura client/server, e poi ampliarlo con funzionalità voip.
Ora devo capire come implementare la mia idea, visto che in partenza volevo farlo in C# ma certi utenti hanno proposto delle idee interessanti, come il websocket, che mi sembra più veloce da realizzare.
Per quanto riguarda la programmazione, da quello che ho capito la parte server sarà molto più complessa della parte client, giusto?
Ora ho dei dubbi sul fatto che il progetto sia alla mia portata :stordita:
Quello che vuoi fare tu è massiccio e richiede un sacco di lavoro. Il linguaggio è francamente l'ultimo dei problemi e molto dipende dai gusti e dalle attitudini personali. Fosse per me ad esempio farei tutto in Python, magari usando Tornado (http://www.tornadoweb.org/en/stable/) o Twisted (https://twistedmatrix.com/trac/) per la parte server.
Voip poi richiede tanta banda e l'uso di algoritmi per nulla banali di compressione e trasmissione dati.
Onestamente la chat la vedo abbondantemente alla tua portata con qualunque linguaggio (è un progetto didattico, non devi servire migliaia di utenti) mentre la parte voip secondo me è troppo per due persone da sole soprattutto se ancora a scuola e a digiuno di reti, protocolli e modelli di traffico.
Non demordete comunque, anche se doveste fallire di sicuro imparerete mille mila cose che non avreste comunque modo di leggere da nessuna parte.
Voip poi richiede tanta banda e l'uso di algoritmi per nulla banali di compressione e trasmissione dati.
Si e no, nel senso che utilizzando WebRTC ad esempio non ti devi preoccupare di algoritmi compressione o quant'altro.
Detto questo comunque dipende da cosa vuol tirar fuori da questo progetto l'utente.
Io fossi in lui visto che è ancora molto giovane e con voglia di imparare mi concentrerei su qualcosa di "moderno" che possa in un futuro portargli un lavoro.
clockover
28-02-2014, 04:00
Io fossi in lui visto che è ancora molto giovane e con voglia di imparare mi concentrerei su qualcosa di "moderno" che possa in un futuro portargli un lavoro.
Tipo?
Inviato da una supercazzola ed un Nexus 5 scappellato a sinistra.. con senso unico
Daniels118
28-02-2014, 08:00
Si e no, nel senso che utilizzando WebRTC ad esempio non ti devi preoccupare di algoritmi compressione o quant'altro.
Detto questo comunque dipende da cosa vuol tirar fuori da questo progetto l'utente.
Io fossi in lui visto che è ancora molto giovane e con voglia di imparare mi concentrerei su qualcosa di "moderno" che possa in un futuro portargli un lavoro.
Didattica e lavoro non vanno molto d'accordo, se ho intuito bene è un progetto per l'esame di stato, e non penso che scatole nere all'avanguardia diano molto valore all'operato dello studente.
tomminno
28-02-2014, 08:33
Per il fatto che scrivi in UN solo linguaggio UNA sola app che può funzionare su qualsiasi computer/smartphone/tablet/device che abbia un browser.
Solo per questo motivo ci si potrebbe fermare qui.
Non è vero che scrivi in un solo linguaggio, sono almeno 3: Javascript, html e CSS. Di ognuno devi conoscere la sintassi e le peculiarità.
Poi che devi stare dietro alla compatibilità con tutti i browser e per tutti i formati. Devi creare interfacce responsive altrimenti ottieni un software inusabile su alcune piattaforme.
Considera poi che girando nel browser la tua app non può eseguire chiamate cross site, se non affidandosi ad html5 e ai browser che lo supportano.
Infine non tutti i servizi lato server supportano il CORS, mi sono trovato a dover cambiare completamente applicativi da puramente client a client+server perchè il server S3 compatibile di turno non supportava chiamate CORS.
Unico protocollo supportato: http
Nel caso della chat, l'invio di messaggi direttamente ad un altro client lo vedo problematico.
Non saprei rispondere su questo punto sinceramente.
Il debug non è proprio comparabile, test automatici nemmeno, entrambi punti a favore dei linguaggi server-side. I pochi profiler che trovi in giro sono limitati allo specifico motore di javascript su cui gira lo script. Che proprio perchè è uno script potrebbe andare benissimo su V8, ma non su SpiderMonkey...
Sono sempre di più le big company che adottano Node, specialmente per le performance.
https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
Sono numeri che fanno impressione.
In passato chi ha seguito la strada delle app mobile in javascript (es usando Phonegap) è tornato indietro sulla via nativa. Il caso più eclatante è stato quello di facebook.
Se poi parliamo di una chat è probabilmente un ambito dove Node.js è un mostro abbinato a websockets.
Ma una chat non è solo scambio dati! Dovrai visualizzarli questi dati, forse dovrai registrarli su un db per evitare di perdere tutto. L'interfacciamento di node.js verso i vari database è un tantino carente, sicuramente non al livello di linguaggi quali C#, Java o PHP.
Seriamente nel 2014 l'html o un framework come bootstrap può essere paragonato in difficoltà a programmare in un linguaggio come C# o Java?
Mi viene un pò da ridere su questo :asd:
Ci puoi scommettere!
E' molto più difficile fare una interfaccia con html e bootstrap che non con C#, pure se ci metti WPF.
Anche solo per la comodità degli editor visuali...
Ti faccio solo un esempio stupidissimo di funzionalità: la riproduzione di un filmato. Su un desktop (esteso anche al mobile) posso usare un qualunque formato supportato dal sistema operativo, sul web ti devi limitare a quanto supportato dal browser per html5 (ogni browser fa storia a sè) o flash (che nel mobile praticamente non è da considerare). E che succede se non hai il filmato in uno di questi formati?
Fai transcodifica video con Javascript?
La realtà a me sembra totalmente diversa, tanto per fare un esempio ieri GitHub ha annunciato che stanno lavorando a un nuovo editor sviluppato totalmente in javascript e basato su node-webkit...e volendo la lista di esempi è lunghissima.
Bisogna capire se è un editor online oppure un editor desktop...
Nel caso sia anche desktop andrebbe poi provato a confronto con tradizionali editor in performance nella ricerca di un testo nei file, nell'apertura di un file di grosse dimensioni ecc...
Direi quindi che quello che hai scritto è più una tua sensazione o pensiero che (per fortuna) non corrisponde alla realtà.
Porta qualche fonte a sostegno della tua idea e possiamo parlarne.
Mah il mondo delle app ha abbandonato la chimera dello sviluppo Javascript. Tanti sono rimasti scottati dalla moda di usare Javascript perchè era tutto bello che uguale in ogni piattaforma, poi la realtà è un'altra: scarse performance, lag, limitazioni tipiche dell'html, necessità di adattamento alle singole piattaforme che risulta comunque necessario... E quindi torni a sviluppare in nativo.
ingframin
28-02-2014, 13:32
Si e no, nel senso che utilizzando WebRTC ad esempio non ti devi preoccupare di algoritmi compressione o quant'altro.
Detto questo comunque dipende da cosa vuol tirar fuori da questo progetto l'utente.
Io fossi in lui visto che è ancora molto giovane e con voglia di imparare mi concentrerei su qualcosa di "moderno" che possa in un futuro portargli un lavoro.
Uaglio', l'amico del sole che ha iniziato il post fa il quinto superiore...
Ora ha la possibilita' di studiare e imparare senza pressione addosso, poi sara' costretto a usare quello che gli imporra' l'azienda.
Conta pure che capire la teoria ti rende molto piu' versatile che non imparare il tool del momento.
Metti che tra 1 anno uscira' la moda di programmare in linguaggio cow (http://web.archive.org/web/20130403133623/bigzaphod.org/cow/): Se chi programma conosce le basi non avra' troppe difficolta' a portare i concetti in un altro linguaggio, se e' una scimmia da codice addestrata all'uso del tool alla moda e basta patira' parecchio per saltare sul nuovo treno.
Onestamente: meglio una cosa piu' semplice ma che ti fa capire la teoria che non una cosa ricca di funzionalita' a scatola chiusa.
Almeno a 18 anni. Poi da grande hai voglia a usare robaccia a scatola chiusa... :muro:
Daniels118
28-02-2014, 13:45
A tal proposito posso suggerire di ripercorrere una strada che ho seguito tempo fa, implementando da zero un sistema di teleconferenza voip multiutente con compressione adpcm, oltre ad aver ottenuto un ottimo (e redditizio) risultato, è stato anche molto educativo.
eriksingh15
28-02-2014, 15:11
Uaglio', l'amico del sole che ha iniziato il post fa il quinto superiore...
Ora ha la possibilita' di studiare e imparare senza pressione addosso, poi sara' costretto a usare quello che gli imporra' l'azienda.
Conta pure che capire la teoria ti rende molto piu' versatile che non imparare il tool del momento.
Metti che tra 1 anno uscira' la moda di programmare in linguaggio cow (http://web.archive.org/web/20130403133623/bigzaphod.org/cow/): Se chi programma conosce le basi non avra' troppe difficolta' a portare i concetti in un altro linguaggio, se e' una scimmia da codice addestrata all'uso del tool alla moda e basta patira' parecchio per saltare sul nuovo treno.
Onestamente: meglio una cosa piu' semplice ma che ti fa capire la teoria che non una cosa ricca di funzionalita' a scatola chiusa.
Almeno a 18 anni. Poi da grande hai voglia a usare robaccia a scatola chiusa... :muro:
Quindi cosa mi suggeriresti di fare? Che via prendere per realizzare la chat, in modo che sia fattibile e allo stesso tempo completa?
eriksingh15
28-02-2014, 15:12
A tal proposito posso suggerire di ripercorrere una strada che ho seguito tempo fa, implementando da zero un sistema di teleconferenza voip multiutente con compressione adpcm, oltre ad aver ottenuto un ottimo (e redditizio) risultato, è stato anche molto educativo.
Puoi darmi qualche dettaglio in più? Grazie :)
Daniels118
28-02-2014, 15:35
Certo, però ti avverto che non potrò fornirti il codice perché ne ho ceduto i diritti all'acquirente.
In pratica c'era un'applicazione server e una client, entrambe sviluppate interamente in vb6.
L'interfaccia dei client era molto semplice, vi era una finestra di configurazione dove veniva specificato un nickname e l'indirizzo del server; sulla finestra principale, un pulsante di chiamata/fine e un tasto "mute".
Il server invece era un po' più elaborato; la finestra conteneva un riquadro principale dove venivano visualizzati tutti gli utenti che partecipavano alla call e tramite menù contestuale era possibile abilitare i microfoni dei singoli utenti o disconnetterli. Altri due pannelli più piccoli consentivano di visualizzare le chiamate in ingresso e quelle perse.
Il cuore del sistema era costituito da tre moduli:
1) mixer - consentiva di combinare i segnali audio provenienti da diversi client;
2) encoder/decoder - codificava i segnali in arrivo con la codifica adpcm che consentiva di dimezzare la larghezza di banda, mantenendo una buona qualità;
3) gestione protocollo - consentiva di veicolare messaggi di servizio (inizio/fine chiamata, blocco microfono ecc...) e stream audio su un unico canale bidirezionale (socket).
Il tutto ovviamente corredato da moduli di IO audio e logica di gestione.
L'applicazione che vuoi realizzare tu ovviamente è diversa, somiglia più a MSN (per il quale ho scritto un bellissimo client in java :D).
eriksingh15
28-02-2014, 16:11
Ovviamente non chiedo il codice :)
Vorrei capire il funzionamento teorico del tutto e i passi per fare il programma, ma il codice ovviamente lo svilupperemo noi.
ingframin
28-02-2014, 16:18
Quindi cosa mi suggeriresti di fare? Che via prendere per realizzare la chat, in modo che sia fattibile e allo stesso tempo completa?
Parti da qui:
http://beej.us/guide/bgnet/
1) Comincia a stendere un minimo di design: che ti serve?
Server:
- Gestore delle connessioni
- Gestore delle stanze
- Database
Client:
- Gestore della connessione
- GUI
2) Comincia a programmare la struttura di base cioe':
- 1 programmino server che accetta le connessioni di piu' client e reindirizza a tutti i messaggi che riceve
- Client testuale che ti consente di scrivere i messaggi e leggere la risposta del server
3) Lato server:
- cerca di capire come gestire le stanze, sai usare i thread? Bene, e' il momento di usarli o di impararli.
Il problema consiste nel gestire separatamente diversi gruppi di client.
Lato client:
- cerca di implementare il meccanismo che ti consente di connettere il client ad una stanza -> legato al punto di sopra
4) Lato server:
- Vedi se ti conviene tenere tutto in RAM o appoggiarti a un database (ti direi SQLite per iniziare. Conosci SQL? Sai progettare un db? Se la risposta a queste due domande e' "no" puoi usare un sistema alternativo (tenere tutto in memoria, salvare su disco, non salvare affatto, ecc...)
Lato client:
Comincia a pensare alla GUI
5) Quando il set minimo di funzionalita' (chat testuale) funziona
puoi implementare le cose fancy tipo:
- stanze private
- comandi al server
- scambio di file
- tracciamento del traffico
- login/logout degli utenti
- connessione via internet
Hai tanto da lavorare, sei sicuro di voler portare questo a luglio all'esame di stato?
Uaglio', l'amico del sole che ha iniziato il post fa il quinto superiore...
Ora ha la possibilita' di studiare e imparare senza pressione addosso, poi sara' costretto a usare quello che gli imporra' l'azienda.
Ho una visione diversa personalmente... eviterei ad ogni costo un azienda che mi IMPONE di utilizzare un determinato linguaggio.
E proprio ora che ha tempo libero a iosa potrebbe dedicarsi a questo...
Non è vero che scrivi in un solo linguaggio, sono almeno 3: Javascript, html e CSS. Di ognuno devi conoscere la sintassi e le peculiarità.
Poi che devi stare dietro alla compatibilità con tutti i browser e per tutti i formati. Devi creare interfacce responsive altrimenti ottieni un software inusabile su alcune piattaforme.
Considera poi che girando nel browser la tua app non può eseguire chiamate cross site, se non affidandosi ad html5 e ai browser che lo supportano.
Infine non tutti i servizi lato server supportano il CORS, mi sono trovato a dover cambiare completamente applicativi da puramente client a client+server perchè il server S3 compatibile di turno non supportava chiamate CORS.
Unico protocollo supportato: http
Nel caso della chat, l'invio di messaggi direttamente ad un altro client lo vedo problematico.
Il debug non è proprio comparabile, test automatici nemmeno, entrambi punti a favore dei linguaggi server-side. I pochi profiler che trovi in giro sono limitati allo specifico motore di javascript su cui gira lo script. Che proprio perchè è uno script potrebbe andare benissimo su V8, ma non su SpiderMonkey...
In passato chi ha seguito la strada delle app mobile in javascript (es usando Phonegap) è tornato indietro sulla via nativa. Il caso più eclatante è stato quello di facebook.
Ma una chat non è solo scambio dati! Dovrai visualizzarli questi dati, forse dovrai registrarli su un db per evitare di perdere tutto. L'interfacciamento di node.js verso i vari database è un tantino carente, sicuramente non al livello di linguaggi quali C#, Java o PHP.
Ci puoi scommettere!
E' molto più difficile fare una interfaccia con html e bootstrap che non con C#, pure se ci metti WPF.
Anche solo per la comodità degli editor visuali...
Ti faccio solo un esempio stupidissimo di funzionalità: la riproduzione di un filmato. Su un desktop (esteso anche al mobile) posso usare un qualunque formato supportato dal sistema operativo, sul web ti devi limitare a quanto supportato dal browser per html5 (ogni browser fa storia a sè) o flash (che nel mobile praticamente non è da considerare). E che succede se non hai il filmato in uno di questi formati?
Fai transcodifica video con Javascript?
Bisogna capire se è un editor online oppure un editor desktop...
Nel caso sia anche desktop andrebbe poi provato a confronto con tradizionali editor in performance nella ricerca di un testo nei file, nell'apertura di un file di grosse dimensioni ecc...
Mah il mondo delle app ha abbandonato la chimera dello sviluppo Javascript. Tanti sono rimasti scottati dalla moda di usare Javascript perchè era tutto bello che uguale in ogni piattaforma, poi la realtà è un'altra: scarse performance, lag, limitazioni tipiche dell'html, necessità di adattamento alle singole piattaforme che risulta comunque necessario... E quindi torni a sviluppare in nativo.
Ti risponderei con quello che ho già scritto non ha senso replicarti di nuovo ad ogni punto.
Mi dai l'idea di una persona con la visione informatica di 10 anni fa.
Abbiamo evidentemente due visioni totalmente diverse non c'è convergenza.
Ti risponderei con quello che ho già scritto non ha senso replicarti di nuovo ad ogni punto.
Mi dai l'idea di una persona con la visione informatica di 10 anni fa.
Abbiamo evidentemente due visioni totalmente diverse non c'è convergenza.
Senza neanche volerlo, si sono presentate alcune notizie su quanto sia valida una soluzione non vecchia di 10 anni:
https://news.ycombinator.com/item?id=7320833
https://news.ycombinator.com/item?id=7321958
http://blog.nodejitsu.com/protecting-npm/ e https://gist.github.com/mikeal/9242748
Passando giusto due commenti presi da la
Node.js is not ready.
The main problem with Node.js is that the libraries out there simply are not good, are broken / don't do what it says it does, or have critical issues outside of the most basic use cases. I'm talking about the popular libraries (like Socket.io) down to all the ones being contributed by the community. I've found flaws in every single library I've used so far, and they are flaws not present in their Python and Ruby counterparts.
Error handling in Node.js is one of the worst of any language.
NPM is now deploying breaking changes to production, without apology.
Javascript is also a terrible language for larger teams, unless everyone follows the same exact convention, as the language itself is extremely flexible, more so than any language I've seen.
I've spent 2 years in this ecosystem, and pretty much anything else feels liberating in comparison, be it Python, Ruby, Go, Erlang, etc etc.
The only thing Node.js has going for it is a community of front-end developers who want to dabble in backend architecture, but I just feel this whole entire ecosystem is too fragile for my tastes.
Like MongoDB, as people begin creating successful businesses out of it and reach a certain scale, similar articles bashing Node.js are all but inevitable.
This has also broken all of our own deploys on Jenkins. We had to use solution 2, and then upgrade, because solution 1 also produces the certificate error.
It was surprising that npm status didn't have any sort of warning. I had to find out about this via twitter. I think it's extremely irresponsible and I'm glad we've started to move away from node.js and started to use Java.
Eh fidiamoci ciecamente di qualche commento di utente random...
Saranno tutti pirla a Linkedin dove hanno adottato node già più di un anno fa e idem paypal che da novembre lo stanno usando ed evangelizzando molto.
Tutte quelle cose che ha citato quell utente sono smontate dai fatti di paypal , cito giusto qualche numero:
- mediamente un team di sviluppatori nodejs(javascript) è da 1/10 fino a 1/3 inferiore come numero ad un team java
- mediamente i programmi vengono scritti con il 30% in meno di righe di codice
- il ciclo di release è passato mi pare di ricordare da mesi a settimane.
- hanno ridotto la quantità di server
- hanno migliorato la risposta di un sacco di ms
Adesso sono dal cel non riesco a cercare comunque eventualmente in serata posto il link alle slide ufficiali.
Fidatevi comunque di questi utenti random mi raccomando
Inviato da mio iPhone usando diti delle mani
tomminno
01-03-2014, 15:20
Eh fidiamoci ciecamente di qualche commento di utente random...
Saranno tutti pirla a Linkedin dove hanno adottato node già più di un anno fa e idem paypal che da novembre lo stanno usando ed evangelizzando molto.
Tutte quelle cose che ha citato quell utente sono smontate dai fatti di paypal , cito giusto qualche numero:
- mediamente un team di sviluppatori nodejs(javascript) è da 1/10 fino a 1/3 inferiore come numero ad un team java
- mediamente i programmi vengono scritti con il 30% in meno di righe di codice
- il ciclo di release è passato mi pare di ricordare da mesi a settimane.
- hanno ridotto la quantità di server
- hanno migliorato la risposta di un sacco di ms
Adesso sono dal cel non riesco a cercare comunque eventualmente in serata posto il link alle slide ufficiali.
Fidatevi comunque di questi utenti random mi raccomando
Inviato da mio iPhone usando diti delle mani
Molti dei punti che citi non dipendono dal linguaggio ma dalle metodologie utilizzate per lo sviluppo (agile sicuramente).
Io potrei citarti stackoverflow che usa Asp.Net MVC per servire centinaia di milioni di pagine al giorno con 25 server (molti dei quali necessari solo per garantire la High Availability).
Quindi come vedi anche soluzioni per chi pensa come 10 anni fa possono essere moderne e al passo con i tempi :D
Molti dei punti che citi non dipendono dal linguaggio ma dalle metodologie utilizzate per lo sviluppo (agile sicuramente).
Io potrei citarti stackoverflow che usa Asp.Net MVC per servire centinaia di milioni di pagine al giorno con 25 server (molti dei quali necessari solo per garantire la High Availability).
Quindi come vedi anche soluzioni per chi pensa come 10 anni fa possono essere moderne e al passo con i tempi :D
due osservazioni:
- se paypal ha ottenuto risultati impressionanti non vuol dire che tutti debbano utilizzare nodejs. non ho mai detto che nodejs va bene per tutto.
- vuoi comparare la complessità di un sito tipo paypal con stackoverflow? :) suvvia
tomminno
02-03-2014, 16:55
due osservazioni:
- se paypal ha ottenuto risultati impressionanti non vuol dire che tutti debbano utilizzare nodejs. non ho mai detto che nodejs va bene per tutto.
- vuoi comparare la complessità di un sito tipo paypal con stackoverflow? :) suvvia
Consigliare ad uno che si affaccia alla programmazione qualcosa che in questo momento è in fase sperimentale mi pare un azzardo. Vediamo come staranno le cose tra 3/4 anni.
Comunque te pensi che la complessità di paypal stia nel frontend? Ci puoi scommettere che il backend di gestione delle transazioni bancarie non è in javascript!
Perché parli di frontend? nodejs è javascript a livello server = backend
Inviato da mio iPhone usando diti delle mani
tomminno
02-03-2014, 22:12
Perché parli di frontend? nodejs è javascript a livello server = backend
Inviato da mio iPhone usando diti delle mani
Dubito seriamente che utilizzino Javascript per le transazioni con le banche e per interfacciarsi con i circuiti internazionali delle carte di credito...
Si ma non capisco dove vuoi arrivare.
Paypal non fa mica solo quelle due cose.
Paypal è prima di tutto un servizio per consumatori e venditori e fornire il migliore servizio a queste due categorie di utenti è il loro obiettivo primario credo di poter dire.
Inviato da mio iPhone usando diti delle mani
http://www.slideshare.net/joemccann/the-business-case-for-node
Inviato da mio iPhone usando diti delle mani
ingframin
03-03-2014, 18:04
Ho una visione diversa personalmente... eviterei ad ogni costo un azienda che mi IMPONE di utilizzare un determinato linguaggio.
E proprio ora che ha tempo libero a iosa potrebbe dedicarsi a questo...
Ovvero il 99,9999999% delle aziende.
La scelta del linguaggio dipende normalmente anche dalla code base esistente,
dalla compatibilita' con quello che si ha, dalle esigenze del cliente, dall'esperienza degli sviluppatori, ecc...
A meno di non trovare lavoro in una start up o di essere molto fortunato e iniziare un progetto da 0 senza dover riusare nulla di precedente forse hai la possibilita' di scegliere il linguaggio.
La mia fortuna e' che non lavoro con niente di esistente e scrivo software piccolissimi ad uso o personale o del mio ristretto team e ho quindi ampie possibilita' di manovra.
Nel momento in cui dovessi lavorare con altri non potrei che attenermi a cio' che mi "cala dall'alto".
Ovvero il 99,9999999% delle aziende.
La scelta del linguaggio dipende normalmente anche dalla code base esistente,
dalla compatibilita' con quello che si ha, dalle esigenze del cliente, dall'esperienza degli sviluppatori, ecc...
A meno di non trovare lavoro in una start up o di essere molto fortunato e iniziare un progetto da 0 senza dover riusare nulla di precedente forse hai la possibilita' di scegliere il linguaggio.
La mia fortuna e' che non lavoro con niente di esistente e scrivo software piccolissimi ad uso o personale o del mio ristretto team e ho quindi ampie possibilita' di manovra.
Nel momento in cui dovessi lavorare con altri non potrei che attenermi a cio' che mi "cala dall'alto".
chiaro che se uno deve mangiare scrive anche codice in assembly.
io credo che uno possa sempre provare, lavorare in una startup è un ottimo punto di inizio secondo me... poi se proprio non trova niente si adatterà a quel che gli offre il mercato per le sue skills
Spezzo una lancia a favore di nodejs. Altro che sperimentale. E' production ready da un po' ed infatti viene usato in parecchie realtà web.
A parte i cs delle slide che ha linkato oozic aggiugo ad esempio "appcelerator" che tanto piccolo e beta non mi pare proprio: usa nodejs per tutto ;)
eriksingh15
03-03-2014, 21:26
Grazie per le risposte.
Io per programmare il lato client opterei per C# dove ho già delle conoscenze.
Ma se scelgo il C# per il Client, sono obbligato a sceglierlo anche per il lato Server? Un mio amico ha detto che il lato server si potrebbe gestire tutto tramite Php, anche se non ho idea di come dovrebbe funzionare in tal caso
Daniels118
03-03-2014, 21:30
No, i programmi si interfacciano tramite un protocollo per il quale possono esserci implementazioni scritte in diversi linguaggi. Puoi addirittura scrivere lo stesso client in linguaggi diversi per distribuirlo su più piattaforme.
tomminno
04-03-2014, 08:40
Spezzo una lancia a favore di nodejs. Altro che sperimentale. E' production ready da un po' ed infatti viene usato in parecchie realtà web.
A parte i cs delle slide che ha linkato oozic aggiugo ad esempio "appcelerator" che tanto piccolo e beta non mi pare proprio: usa nodejs per tutto ;)
Fino a non molto tempo fa le performance di appcelerator su Android erano pessime :mad:
Magari ultimamente hanno migliorato sotto questo aspetto, io non ci reinvestirei un centesimo.
Fino a non molto tempo fa le performance di appcelerator su Android erano pessime :mad:
Magari ultimamente hanno migliorato sotto questo aspetto, io non ci reinvestirei un centesimo.
E ma cosa c'entra? nodejs è lato server, il backend dei loro servizi e tutta l'infrastruttura viene gestita con nodejs. Titanium compila in nativo. Io non ho mai sentto di così scarse performance su android, certo non è come su ios ma poco ci manca.
Comunque non soffermiamoci su appcelerator, il mio era solo un appunto.
Tornando in topic il futuro è il web, meglio usare tecnologie nate per il web. websocket + nodejs credo sia il giusto approccio. Non a caso il 99,9% delle chat che si trovano su internet su portali, siti di ecommerce ecc. per assistenza e pre-sales sono fatte così. Ci sarà un motivo no?
Daniels118
04-03-2014, 10:20
Il motivo è come sempre quello di risparmiare sullo sviluppo per massimizzare il profitto. Il web va sempre di più verso standard condivisi, mentre le applicazioni native richiedono di riscrivere il codice per le piattaforme specifiche.
Il motivo è come sempre quello di risparmiare sullo sviluppo per massimizzare il profitto. Il web va sempre di più verso standard condivisi, mentre le applicazioni native richiedono di riscrivere il codice per le piattaforme specifiche.
sembra che lo dici quasi con disprezzo.. "risparmiare sullo sviluppo" :asd:
E ma cosa c'entra? nodejs è lato server, il backend dei loro servizi e tutta l'infrastruttura viene gestita con nodejs. Titanium compila in nativo. Io non ho mai sentto di così scarse performance su android, certo non è come su ios ma poco ci manca.
Comunque non soffermiamoci su appcelerator, il mio era solo un appunto.
Tornando in topic il futuro è il web, meglio usare tecnologie nate per il web. websocket + nodejs credo sia il giusto approccio. Non a caso il 99,9% delle chat che si trovano su internet su portali, siti di ecommerce ecc. per assistenza e pre-sales sono fatte così. Ci sarà un motivo no?
+1
tomminno
04-03-2014, 12:08
E ma cosa c'entra? nodejs è lato server, il backend dei loro servizi e tutta l'infrastruttura viene gestita con nodejs. Titanium compila in nativo. Io non ho mai sentto di così scarse performance su android, certo non è come su ios ma poco ci manca.
Comunque non soffermiamoci su appcelerator, il mio era solo un appunto.
Tornando in topic il futuro è il web, meglio usare tecnologie nate per il web. websocket + nodejs credo sia il giusto approccio. Non a caso il 99,9% delle chat che si trovano su internet su portali, siti di ecommerce ecc. per assistenza e pre-sales sono fatte così. Ci sarà un motivo no?
Dato che la chat del topic non è web, siamo sicuri che l'utilizzo di tecnologie web sia la scelta più indicata?
Dopotutto i market delle varie piattaforme mobile non hanno fatto altro che spingere nuovamente verso uno sviluppo desktop style, in un momento in cui sembrava che html fosse la panacea per tutto. E ancora non lo è ;)
Daniels118
04-03-2014, 12:23
sembra che lo dici quasi con disprezzo.. "risparmiare sullo sviluppo" :asd:
+1
Non è questione di disprezzo ma di punti di vista. Ci sono applicazioni per le quali le prestazioni non sono importanti ed altre per le quali lo sono, e storicamente risparmio e prestazioni non vanno d'accordo, tutto qui.
Dato che la chat del topic non è web, siamo sicuri che l'utilizzo di tecnologie web sia la scelta più indicata?
Dopotutto i market delle varie piattaforme mobile non hanno fatto altro che spingere nuovamente verso uno sviluppo desktop style, in un momento in cui sembrava che html fosse la panacea per tutto. E ancora non lo è ;)
La scelta di realizzare applicazioni native per piattaforme mobile penso derivi dal vantaggio di non dover trasferire in continuazione anche la parte "grafica" dell'applicazione, cosa non di poco conto se si considera che tali piattaforme navigano generalmente con contratti a consumo. Questo problema è parzialmente ridotto con l'utilizzo di ajax, ma non eliminato del tutto.
Dato che la chat del topic non è web
chi l'ha detto scusa? :)
Guarda io fossi in te farei un progetto web con websocket e nodejs lato server.
Un solo linguaggio = javascript, che è abbastanza semplice.
L'applicazione funzionerebbe sia su desktop sia su mobile senza problemi.
Come primo step fai un' app dove ti connetti ad un server e 2+ devices parlano in una stanza. Poi volendo ci aggiungi stanza privata e poi voip.
La demo la fai con device mobili. Tu e il tuo amico che chattate. Mi pare un buon esercizio, semplice ma non troppo e d'effetto. Per uno che fa il quinto superiore.
Poi vedi tu.
ingframin
04-03-2014, 15:12
Guarda io fossi in te farei un progetto web con websocket e nodejs lato server.
Un solo linguaggio = javascript, che è abbastanza semplice.
L'applicazione funzionerebbe sia su desktop sia su mobile senza problemi.
Come primo step fai un' app dove ti connetti ad un server e 2+ devices parlano in una stanza. Poi volendo ci aggiungi stanza privata e poi voip.
La demo la fai con device mobili. Tu e il tuo amico che chattate. Mi pare un buon esercizio, semplice ma non troppo e d'effetto. Per uno che fa il quinto superiore.
Poi vedi tu.
Non e' affatto semplice per uno che fa il quinto superiore!
Lascialo giocare con C# che gia' ha un'infarinatura.
@tutti:
gli esami di stato sono a giugno/luglio e siamo gia' a marzo! :muro:
Daniels118
04-03-2014, 15:22
Ribadisco che non ci trovo nessun merito nel mettere insieme un paio di moduli scritti da altre persone, se fossi un professore non potrei far altro che prendere atto dell'esemplare interpretazione del manuale di istruzioni.
eriksingh15
04-03-2014, 15:32
Ribadisco che non ci trovo nessun merito nel mettere insieme un paio di moduli scritti da altre persone, se fossi un professore non potrei far altro che prendere atto dell'esemplare interpretazione del manuale di istruzioni.
Quindi secondo te scriverlo in C# è meglio?
tomminno
04-03-2014, 15:37
Guarda io fossi in te farei un progetto web con websocket e nodejs lato server.
Un solo linguaggio = javascript, che è abbastanza semplice.
Da quando si riesce a fare grafica con Javascript?
Ribadisco che non ci trovo nessun merito nel mettere insieme un paio di moduli scritti da altre persone, se fossi un professore non potrei far altro che prendere atto dell'esemplare interpretazione del manuale di istruzioni.
Farlo in js + node o in C# sotto questo punto di vista è la stessa cosa. Si tratta di usare librerie già pronte.
Farlo in C#o anche solo in C puro modello multi client/server non bloccante (parlo del C che lo conosco un poco) saranno si e no 30 righe di codice (senza libreri esterne, quindi socket: accept, polling, read/write) per il client e altrettante sul server. Quindi chissà quale esercizio...
Da quando si riesce a fare grafica con Javascript?
Da quando puoi usare i canvas/webGL :D
Comunque so che non è quello che volevi sentirti dire. La parte grafica si fa in html e css ok ma in questo caso (chat) siamo a livell da prima superiore quanto a difficoltà. Una text area, un textfield, un submit. Fine. Puoi pure lasciare tutto bianco e agire solo sulle larghezze.
Daniels118
04-03-2014, 15:47
Sono sempre stato dell'opinione che ciò che conta non è il linguaggio, ma gli algoritmi. Scegli liberamente il linguaggio, ma abbi cura di implementare tu stesso gli algoritmi.
Ovviamente non sto dicendo che devi riscrivere il sistema operativo da zero, ma almeno uno strato software che contenga qualcosa su cui discutere devi mettercelo.
Per intenderci, se fai una chat utilizzando il fantastico bellissimo e potentissimo plugin ChatNow (nome di fantasia), otterrai un risultato stupendo; ora il professore ti dice: <<Bello... come funziona?>> e tu gli rispondi: <<Semplice, basta chiamare il metodo "ChatNow.init()"!>>, il professore comincerà a chiederti di scrivere l'algoritmo per l'inserimento in testa nelle linked list.
Potresti invece dire di aver implementato una architettura client/server esponendo tanto di disegni, spiegare che quando l'hai realizzato hai dovuto risolvere il problema di distinguere i messaggi di controllo dal testo inserito dall'utente e quindi hai dovuto scegliere tra codifica base64 e payload - cosa che ad alcune persone non passa manco per la mente - e più riesci a fare più puoi parlare.
Se è a scopo accademico e di tesina; potresti complicarti la vita sviluppandola in c# ed implementandola tramite il mediator pattern cosi puoi discutere anche dell'utilizzo dei design pattern.
http://www.dofactory.com/Patterns/PatternMediator.aspx
Se vuoi fare qualcosa di produttivo ed eventualmente farlo diventare un progetto concreto quoto completamente i post precendenti e ti consiglio di usare una soluzione open che implementa la videoconferenza tramite websocket / webRTC
http://tokbox.com/opentok
e la parte di chat pura magari te la fai da solo usando nodejs e websocket
Se è a scopo accademico e di tesina; potresti complicarti la vita sviluppandola in c# ed implementandola tramite il mediator pattern cosi puoi discutere anche dell'utilizzo dei design pattern.
http://www.dofactory.com/Patterns/PatternMediator.aspx
Se vuoi fare qualcosa di produttivo ed eventualmente farlo diventare un progetto concreto quoto completamente i post precendenti e ti consiglio di usare una soluzione open che implementa la videoconferenza tramite websocket / webRTC
http://tokbox.com/opentok
e la parte di chat pura magari te la fai da solo usando nodejs e websocket
E' al quinto superiore non a fare un esame di algoritmi o informatica 3 o programmazione agli oggetti. :D
Stiamo facendo voli pindarici. eriksingh15 parlane anche col tuo professore che magari sarà pure in commissione e vedi cosa ti consiglia lui!
PS. nodejs è il futuro
tomminno
04-03-2014, 20:36
Da quando puoi usare i canvas/webGL :D
Comunque so che non è quello che volevi sentirti dire. La parte grafica si fa in html e css ok ma in questo caso (chat) siamo a livell da prima superiore quanto a difficoltà. Una text area, un textfield, un submit. Fine. Puoi pure lasciare tutto bianco e agire solo sulle larghezze.
Vorrai anche visualizzare lo storico della conversazione?
Sicuramente con C# riesci a tirare fuori qualcosa di graficamente accettabile più facilmente che non lottando con html5 e css3 che diciamolo semplicissimi non sono!
WebGL semplicissimo da usare ;) Poi su IE funziona solo con l'11 :D
Se lo scopo e' fare una tesina per la maturita', inutile fare voli pindarici su quello che sara' il framework del futuro, o le tecnologie in voga presso team di una certa grandezza e con anni di esperienza. Necessita' diverse e tanto tra cinque anni la "tecnologia del futuro" sara' nuovamente cambiata.
(Quando ho cominciato l'universita' io il futuro erano le applet Java. Abbiamo visto come e' finita...)
Andare a suggerire di usare js+html+css+websockets ad uno che conosce gia' almeno un po' C#, e in piu' ha gia' implementato la versione diretta tra utenti mi sembra decisamente poco pragmatico. Meglio spiegargli come strutturare la versione client-server (cosa che in realta' qualcuno ha gia' fatto, ma se ancora non e' chiaro possiamo spiegare ulteriormente).
eriksingh15
06-03-2014, 11:52
Se lo scopo e' fare una tesina per la maturita', inutile fare voli pindarici su quello che sara' il framework del futuro, o le tecnologie in voga presso team di una certa grandezza e con anni di esperienza. Necessita' diverse e tanto tra cinque anni la "tecnologia del futuro" sara' nuovamente cambiata.
(Quando ho cominciato l'universita' io il futuro erano le applet Java. Abbiamo visto come e' finita...)
Andare a suggerire di usare js+html+css+websockets ad uno che conosce gia' almeno un po' C#, e in piu' ha gia' implementato la versione diretta tra utenti mi sembra decisamente poco pragmatico. Meglio spiegargli come strutturare la versione client-server (cosa che in realta' qualcuno ha gia' fatto, ma se ancora non e' chiaro possiamo spiegare ulteriormente).
Esatto :)
http://www.nearform.com/nodecrunch/node-js-becoming-go-technology-enterprise#.Ux3AeOd_uLt
dolfrang
12-03-2014, 23:03
Rimanendo su C#, e senza voler entrare nel merito sul valore didattico o meno dall'usare librerie esistenti, potrebbe appoggiarsi a SignalR (http://www.asp.net/signalr) (Web Sockets) o XSockets (http://xsockets.net/) (Web Sockets e WebRTC).
In entrambi i casi il server è scritto in C# mentre il client è realizzabile sia in Javascript che in C#.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.