Maciej Sobczak pisze:
> Nie warto robić takiego systemu na zasadzie odpytywania, bo przy
> pomiarach fizycznych odpytywanie jest najczęściej albo jałowe jeśli
> jest zbyt częste, albo pomijające ciekawe zmiany jeśli jest za wolne.
Zgoda, aczkolwiek ma to znaczenie raczej przy rejestracji tego typu
danych, a nie np. prezentacji chwilowych wartości. Na pewno nie ma co
powielać tego mechanizmu, czyli jeśli na etapie serwera _musi_ być
czasowe odpytywanie (bo czujniki są raczej "głupie"), to rzeczywiście
bez sensu jest pisać podobnie "głupi" serwer, który też trzeba czasowo
odpytywać.

> Lepiej odwrócić kierunek stymulacji i oprzeć się na subskrypcji - tzn.
> niech czujniki (albo kontrolujący je serwer, zależnie od inteligencji
> czujnika) wyznaczają rytm i niech wysyłają dane do klientów wtedy, gdy
> warto je wysłać. Np. wtedy, gdy się gwałtownie zmieniają albo gdy
> osiągają jakieś progowe wartości.
> Wtedy oczywiście pojawia się ciekawy problem zarządzania subskrypcjami
> (komu co wysłać), ale na dłuższą metę warto w to zainwestować..
W sumie ta jednostanowiskowa aplikacja już tak działa, tzn. poszczególne
okna w momencie otwarcia wiążą swoje elementy ze zmiennymi w "module"
komunikacyjnym i przy zmianie wartości zmiennej wymuszane jest
odświeżenie stanu powiązanych elementów. Teraz muszę się poważnie
zastanowić dlaczego chciałem zrobić 2 kroki do tyłu i montować jakieś
czasowe odświeżanie elementów z jednoczesną komunikacją po sieci. To
musi być starość ;-)

> Tak czy inaczej nie ma po co męczyć się z ręcznie obsługiwanymi
> gniazdami, lepiej skorzystać z gotowców nastawionych na przesyłanie
> komunikatów.
A możesz coś polecić szczególnej uwadze?

--
Pozdrawiam
Maciek