Michoo <m...@v...pl> napisał(a):
> On 20.05.2012 01:48, Grzegorz Niemirowski wrote:
>> Gorzej jest natomiast w drugą stronę, bo chodzi o
>> to, żeby to działało w czasie rzeczywistym. Aplikacja webowa raczej nie
>> może otworzyć sobie portu szeregowego i czekać aż coś dostanie.
> Ponieważ?
> Albo servlet javy na serwerze aplikacji z dodatkową klasą ładowaną w init
> (tomcat/glassfish/etc), albo np aplikacja w C++ podpięta przez fastcgi do
> apache.

OK, nie znam się na servletach i fast CGI i stąd moje myślenie jest pewnie
prymitywne i przestarzałe. Otóż wyobrażałem sobie to tak, że jak leci HTTP
GET to wtedy na serwerze odpala się jakieś PHP, które coś tam robi i zwraca
wynik. A taki port szeregowy musi być monitorowany cały czas, czyli musi
chodzić coś w rodzaju demona.

>> Generalnie chodzi mi o coś takiego, że jest sobie urządzenie z
>> przyciskiem. Naciśnięcie tego przycisku powoduje wysłanie jednego bajtu
>> przez RS-232 do komputera na którym stoi demon HTTPD. Jak to potem
>> sensownie przesłać do przeglądarki, z możliwie małym opóźnieniem?
> Ajax. Najlepiej jakiś framework który wywołania callbacków zrobi za
> ciebie. Ja kiedyś używałem GWT.

Dzięki.

>> Da się
>> to jakoś lepiej rozwiązać niż komunikacja przez pliki z zewnętrzną
>> aplikacją odpowiedzialną za port szeregowy?
> Nie napisałeś jaki system operacyjny - pod linuksem port szeregowy jest
> "jakimś plikiem".

Tak samo jak pod Windows i innymi systemami. A systemu nie podawałem bo
chciałem jakąś ogólną ideę, najlepiej prostą i przenośną. Jeśli już coś
miałbym wskazać to Apache (raczej na Linuksie) i PHP, bo jest to popularna
kombinacja, łatwa do wdrożenia i często już dostępna.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 3 hours, 5 minutes and 33 seconds