Newsgroup: it.hobby.elettronica.digitale
Titolo: Applicazioni grafiche web

Ciao,
domanda parzialmente OT.
Attualmente quale è la strada migliore (*) per sviluppare applicazioni 
web "grafiche" che risiedano su un piccolo web server linux? Qualche 
dettaglio in più:
- web server su scheda tipo fox board G20, per intenderci
- qualche pagina che mostri i soliti pulsanti / gauge per I/O digitali e 
analogici, possibilmente basati su svg
- facile interfaccia con database e periferiche hardware (anche tramite 
applicazione separata)
La domanda è rivolta principalmente al tipo di linguaggio e ambiente di 
sviluppo per la parte di codice.
(*) per "migliore" intendo che sia maggiormente compatibile con i vari 
browser (anche mobili) e che non sia una tecnologia già obsoleta.
Grazie!
Marco

 web "grafiche" che risiedano su un piccolo web server linux?
[CUT]
Non so se e' il migliore, ma per applicazioni grafiche suggerisco la 
libreria raphaeljs che in versione mini occupa da sola 60kB.
http://raphaeljs.com/
Ciao
s.

 
Ma si occupa solo di grafica?
Recentemente mi sono imbattuto in Batman.js [1] e l'ho messo nei 
segnalibri.
[1] 
http://batmanjs.org/

 
IBM Rational Raphsody lo fa alla grande, ma non c'entra niente con tutte le 
altre specifiche :)
-- 
"Non č mai troppo tardi per imparare a suonare..."
"Sě bhč, magari alle 3 di notte evita."

 
http://raphaeljs.com/
Scusa il ritardo con cui rispondo.
Molto interessante la libreria suggerita!
Domanda più generale: c'è un testo aggiornato di riferimento (cartaceo, 
pdf, sito, ...) che tratti in maniera concreta la programmazione web con 
particolare attenzione ai database e all'interfaccia utente?
Concreta nel senso che non dica solo cosa si può fare, ma come si 
*dovrebbero* fare le cose. Per farle bene.
Per imparare questa tecnologia vorrei realizzare un web server su una 
scheda embedded in grado di acquisire dati (es. da seriale) e tramite un 
db mostrarli graficamente in una pagina web in real-time.
Mi interessa quindi capire come far convivere più applicazioni (il 
"driver" che acquisisce i dati, eventuali elaborazioni sul db, 
l'applicazione web vera e propria) ma soprattutto come meglio 
distribuire il carico di lavoro tra server e client tenendo presente la 
massima compatibilità anche con browser mobili.
Grazie ancora
Marco


Ciao Marco, anche io ho una foxg20 e sto cercando le tue stesse info...
Per il webserver prova lighttpd,per il codice c/c++ e python, per la 
grafica aspetto suggerimenti pure io.
Sono ancora agli albori...ma voglio poter comandare la fox via web :)

 Sono ancora agli albori...ma voglio poter comandare la fox via web :)
 
 
Penso sia quello che vogliono fare tutti quando hanno una scheda con un 
webserver, per questo non ha senso inventare l'acqua calda ma capire 
cosa fanno gli altri!
 
Marco


wrote:

Invece di installare un server di DB (sulla fox o altrove nel web ?)
potrebbe essere molto più semplice scrivere i dati su un file di log o
semplicemente su un file contenente un numero di record che ti
interessa (gli ultimi N).
Le funzioni/classi per leggere/scrivere su file sono semplici veloci e
non portano via spazio.
Un server DB per quanto piccolo occupa spazio.
Se non hai bisogno di filtrare le informazioni con SELECT particolari
o complesse io opterei per lavorare su file.
 
Se il server (del DB) si trova nel web e non nella scheda di
acquisizione ovviamente devi crearti un sistema di buffer per
'tamponare' le condizioni di off-line.

 'tamponare' le condizioni di off-line.
 
 
No, la scheda deve essere completamente autonoma. Offre solo la 
possibilità di essere accessibile dall'esterno tramite web-server, ma 
tutti i dati devono restare al suo interno.
 
Ciao e grazie
Marco

Se vuoi sperimentare c'è SqLite (
http://www.sqlite.org/
) che è un
ottimo DB e occupa solo qualche centinaio di KByte.
E' open source e freeware. Viene usato anche da Mozilla, Nokia,
Apple, ...
Ha la limitazione però che SOLO UN PROCESSO PUO' SCRIVERE (INSERT o
UPDATE):
lavora su un unico file dove è contenuto tutto il db.
 
Per gestire la sincronizzazione tra più file (2 se ho capito) puoi
semplicemente usare il Lock dei file del sistema operativo (Linux
giusto ?) avendo cura nelle 3 applicazioni di bloccare sempre entrambi
prima di fare qualunque altra operazione. Ricorda di bloccarli sempre
nella stessa sequenza per evitare DeadLock.
esempio:
lock file IN
lock file OUT
lettura e/o scrittura
unlock file IN
unlock file OUT
 
Oppure puoi usare un unico semaforo prima di fare qualunque operazione
sia di lettura che di scrittura.
 
Se piu' di un'applicazione va a modificare lo stato degli stessi
attuatori devi prevedere una variabile di stato (in uno degli xml) che
permetta di capire come agire sull'attuatore, altrimenti
un'applicazione lo imposta in un modo e un'altra subito dopo potrebbe
cambiarne lo stato.
Una possibilità allora potrebbe essere quella di avere 3 file xml
diversi: ingressi.xml, uscite.xml e comandi.xml dove un solo processo
(in polling ad esempio) va a modificare le uscite.
Ma la struttura si può organizzare in infiniti modi diversi, in ogni
caso sei tu a doverti sobbarcare il lavoro di sincronizzazione, il
sistema operativo fornisce gli strumenti di comunicazione di base tra
processi (semafori, pipe, file, ...).
Anche usando un DBserver hai a disposizione degli strumenti di base
(semafori, transazioni) che poi devi gestire tu.
 
Se il lavoro che devi fare non implica troppe combinazioni di IN/OUT
magari te la cavi senza usare troppi meccanismi di sincronizzazione.
 
Sto scrivendo un po 'a caso' nel senso che non ho ben chiaro che cosa
si deve fare, ma spero di aver fornito qualche suggerimento utile in
base alla (poca) esperienza che ho.
Ciao
Stefano

 base alla (poca) esperienza che ho.
 
 
E certamente ti ringrazio per i consigli. Non essendo un'applicazione 
definita ma appunto un modo per imparare sto semplicemente cercando di 
potermi interfacciare con schede di I/O e gestire da remoto.
 
Una limitazione che vedo nell'utilizzare i lock dei file o anche del db 
sqlite è l'impossibilità di scrivere contemporaneamente su due file o 
tabelle diverse. Esempio:
 
- sensore di pressione/posizione/quellochevuoi
- attuatore on-off
 
Sarebbe molto interessante poter acquisire "rapidamente" e con 
continuità così da attivare l'attuatore al momento giusto.
 
Marco
 

 
i semafori sono (dovrebbero) essere supportati a livello di kernel,
vedi se questa introduzione all'argomento e' sufficiente
http://beej.us/guide/bgipc/
altrimenti approfondisci
altri argomenti interessasti sono le pipes ( non il | della shell ) la 
shared memory fra processi, ed in ultima analisi i file mappati in 
memoria che possono essere anche condivisi fra piu' processi.

 continuità così da attivare l'attuatore al momento giusto.
Non sono sicuro si adatti al tuo caso ma hai pensato di usare un sistema 
di messaggi come zeromq? Dovresti poter risolvere la concorrenza ed ha 
una latenza estremamente bassa, io gli ho dato una occhiata veloce 
quando ho compilato Mongrel2.

 quando ho compilato Mongrel2.
 
 
Non lo conosco, vado a vedere di che si tratta!
Marco

 memoria che possono essere anche condivisi fra piu' processi.
 
 
Grazie delle dritte, vado a informarmi sulle varie strade e vedo cosa 
salta fuori.
 
Marco

 salta fuori.
Ci fai sapere poi, se possibile, che strada hai scelto ?
Io personalmente sono curioso.
Ciao
Stefano

 Io personalmente sono curioso.
 
 
Volentieri. Certo non sarà una cosa rapidissima visto che ci "gioco" nei 
ritagli di tempo...
 
Marco
 
 

 ha scritto nel messaggio 
news:j4scae$rp8$2...@tdi.cu.mi.it...

Hai preso in considerazione Labview ?
Fa esattamente quello che chiedi, puoi visualizzare dati provenienti da 
qualsiasi fonte, oltre che elaborarli e memorizzarli nei formati piu' 
diffusi
E' programmabile, molto diffuso, ben supportato
Costicchia, dal migliaio di euro in su, ma essendo che non hai posto limiti 
di finanze forse anche questo puo' essere un 'papabile'
Ciao
RobertoA
 
 
 

 di finanze forse anche questo puo' essere un 'papabile'
 
 
Onestamente non mi è mai stato molto simpatico LabView. Proverò a 
riconsiderarlo. Certo il costo non è indifferente, bisogna vedere i 
prezzi delle licenze dei run-time per volumi considerevoli.
 
Ciao!
Marco
 

 Io personalmente sono curioso.
 
 
Qualche aggiornamento. Nel cercare una cosa ne ho trovata un'altra: Processing. Mi sembra abbastanza comodo e semplice per realizzare interfacce grafiche interattive. 
 
Ho fatto una prova veloce e ho messo un esempio in una pagina html nel webserver della fox board. Probabilmente con Processing.js è anche possibile accedervi dagli smartphone (che non supportano Java ma solo JavaScript).
 
Processing viene eseguito lato client. Questo è positivo, ma complica un poco il trasferimento dei dati (lettura e scrittura).
 
Una possibilità sarebbe quella di comunicare tramite le funzioni di rete: collegarsi a un processo server e scambiare dati con lui.
 
Fattibile è fattibile, però non mi piace.
Che voi sappiate, c'è un modo trasparente per collegare applicazioni lato server e lato client?
 
Per trasparente intendo semplicemente accedere in lettura/scrittura a variabili condivise con l'applicazione sorella residente sul server. Quest'ultima si interfaccia all'hw sottostante (seriali, I/O, file, ecc...) e scambia con queste variabili.
 
Se però pensiamo di voler implementare questa cosa anche su piattaforme relativamente leggere (es. Arduino Ethernet o simili) forse è ancora conveniente la programmazione di rete classica?
 
Marco

 Se però pensiamo di voler implementare questa cosa anche su piattaforme
 > relativamente leggere (es. Arduino Ethernet o simili) forse è ancora
 > conveniente la programmazione di rete classica?
 
Intendi un protocollo proprietario su TCP/IP "grezzo" su porte non 
standard?  Non penso che XMLHttpRequest sia così pesante sul server, 
visto che si tratta comunque di richieste HTTP.  Immagino non dovrai 
aspettarti performance largamente più negative del normale scaricamento 
delle pagine web.
 
Curiosità: che server web utilizzi?  Sei sotto linux (pardon se l'hai 
già scritto in un precedente post).

Il 04/12/2011 17:30, 
marcotr...@gmail.com
 ha scritto:

link?
 
magari se posti qualcosa su megaupload (intendo roba fatta girare sulla 
fox....ne ho una che sbava....)

 Per trasparente intendo semplicemente accedere in lettura/scrittura a variabili condivise con l'applicazione sorella residente sul server. Quest'ultima si interfaccia all'hw sottostante (seriali, I/O, file, ecc...) e scambia con queste variabili.
confermo che tramite il protocollo http puoi trasferire valori con
nome (quindi semplici variabili) dal client al server (in get o in
post) ed eventualmente ricevere una risposta dal server tramite
'scansione' della pagina html.
Esempio: 
www.miapagina.it/prova.php?cmd=salvat&t=45
 
il server riceve la variabile cmd con valore "salvat" e la variabile t
con valore="45".
Il metodo ideale per scambiare dati, anche complessi, tra client e
server è tramite l'uso dei web services. Si tratta, normalmente, di
file xml scambiati tramite un protocollo, di solito, SOAP.


 di solito, SOAP.
 
Leggo che si usa tanto anche JSON grazie alla grande diffusione che sta 
conoscendo js anche come linguaggio standalone.

 scritto in un precedente post).
 
 
Attualmente sto facendo le prove con Debian e lighttpd.
 
Ciao!
Marco

 fox....ne ho una che sbava....)
 
 
Non ha senso un link... ho semplicemente preso un esempio di quelli in 
dotazione a Processing ho fatto esporta applet e l'ho messo in /var/www. 
Tutto qui :)
 
Marco

 file xml scambiati tramite un protocollo, di solito, SOAP.
 
 
Provo a guardare anche questo SOAP.
 
Ciao!
Marco
 

 conoscendo js anche come linguaggio standalone.
 
 
Argh, terza sigla da investigare di oggi, dopo Ajax e SOAP :)
Ciao!
 
Marco

 Argh, terza sigla da investigare di oggi, dopo Ajax e SOAP :)
 
È un formato per incapsulare i dati, è "nativo" per Javascript nel senso 
che usa la sua sintassi, tu lo ricevi, lo esegui e hai le variabili 
pronte, se sei in ambiente Javascript…

 scoprire di nuovo l'acqua calda.
 
 
Trovato tutto sul sito 
http://www.w3schools.com/ajax/
 
 
Marco
 

 l'ho specificato ma è ovvio che lo scambio dati deve essere ripetuto.
 
 
Le risposte a queste domande sono nel sito già segnalato:
 
http://www.w3schools.com/ajax/
 
 
Marco
 

 Sicuramente HTTP è l'ideale visto che il canale è già aperto.
 
Infatti.

 Perché vorresti evitare la connessione inter-process?
 
 
Perché mi sembrava piů semplice e facilmente integrabile in ambienti 
limitati (leggi senza OS).
 
Comunque, ho fatto qualche prova con Ajax e php e sono riuscito a 
inviare e ricevere dati.
 
Ora manca appunto l'interfacciamento dello script lato server (php) con 
qualcos'altro. Per iniziare posso banalmente utilizzare un xml per 
leggere/scrivere i dati.
 
 
Ciao
Marco