Andiamo OT probabilmente, ma sarà il moderatore al limite a dirci se andare in pvt o continuare. cmq accenniamo una ipotesi:
su raspi gira un processo, che definiremo un pò impropriamente "server" o meglio "server locale", che una volta lanciato prende e instaura una connessione col server remoto e si preoccupa a) di mantenerla attiva b) di ascoltare i messaggi in arrivo c) di inviare messaggi in uscita . Tale server locale apre un socket in ascolto su 127.0.0.1:PORTA e attende che qualche client ci si connetta. Da locale(ovvero dal raspi), apri un browser e ti connetti via websocket a 127.0.0.1:PORTA e inizi a dialogare con il server locale, il quale userà tale socket per girarti messaggi o per permetterti a te di inviarne di tuoi da client web. Possiamo dividere i messaggi in varie tipologie: comandi sincroni, comandi asincroni, eventi. il server locale è altresi il processo che avrà il compito di a) decidere cosa persistere in locale, b) decidere cosa mandare al client connesso alla 127.0.0.1:PORTA, c) decidere se accettare 1 o piu client su tale porta e quindi magari invece di essere in ascolto solo su 127.0.0.1 aprirsi a tutta la rete, d) gestione sicurezza/acl/riconoscimento utente/interazioni varie con altri sistema software... insomma, il cuore di tutto sarà lui mentre tutto il resto servirà solo da "interfaccia" verso di questo server locale.
insomma, detto così alla carlona è tutto facile, andarlo ad implementare è tutta un'altra storia.
Per questo scartavo PHP come linguaggio: anche se è vero che "php fà tutto", è anche vero che la strada che ha preso il linguaggio lo porta ad essere selettivo nei compiti che può svolgere, a meno di non fare affidamento su "tanto codice scritto a mano" e non affidarsi invece a frameworks o linguaggi che rispondono in maniera più solida alle esigenze riscontrate.
Che te lo sto a dire a fare: java, su multithreading e comunicazioni via socket, offre tools e frameworks inesistenti in php, che consentono terribilmente tanto al programmatore di concentrarsi non su "come faccio a mandare un messaggio da A a B" ma su "che ce fa B co sto messaggio mo?".
Credo che anche roba tipo node.js offra molte soluzioni in merito (soprattutto lato websockets, con frameworks tipo socket.io/expressjs ), anche perchè lato client web il websockets lo apri con javascript mica con php (e allora usando il mondo nodejs hai una pletora di framework per fare applicazioni "live" lato client).
Con altri linguaggi non so, non ho esperienza in merito.
Per non parlare poi del protocollo di comunicazione che tutti sti oggetti adotteranno: custom? xmpp? soap ? soap+xmpp ? altri?
E avoja ancora, ho qui accanto 3 libri che parlano dell'argomento e sono solo un assaggio
Buonanotte
EDIT: ovviamente parlo pensando ad una riprogettazione partendo da 0. Nulla ti vieta di cominciare a modificare aspetti della tua applicazione senza dover ricominciare da 0. Es: facendo il refactory intanto del client web sul raspi per parlare con il php via websockets, ad esempio usando lato php librerie come http://socketo.me/ (a giudicare dalla documentazione, sembra una cosa molto interessante)
Rispondi quotando