Jedni pchają, inni ciągną
2013-12-29
Rozważmy hipotetyczną sytuację: chcemy się napić z kolegą. Sytuacja ta jest hipotetyczna dla części z Was, dla innych to czwartek, 11:30. Mamy dwa scenariusze.
Scenariusz pierwszy
Wsiadasz w komunikację miejską, pokonujesz n przystanków. Wysiadasz. Wchodzisz na klatkę i łomocesz do drzwi. Kolega otwiera, a na pytanie o wspólne picie mówi, że jeszcze od wczoraj mu nie zeszło. Wracasz więc do domu, rzucasz palto i czekasz cały kwadrans. Zakładasz palto i wsiadasz w komunikację miejską. Wysiadasz, klatka, a kolega nadal to samo. Jaki debil.
Wracasz, wstawiasz wodę, zjadasz torebkę Sagi i wpijasz duszkiem wrzątek. Kierowca komunikacji miejskiej kiwa Ci głową i pyta, czy tam, gdzie zwykle. Tam. Tym razem nikt nie odpowiada. Jedziesz do szpitala na płukanie żołądka po herbacie Saga. Wsiadasz w komunikacje miejską, siedzący obok Syzyf kręci głową z dezaprobatą.
Dwa dni później kolega otwiera ci i zaprasza szerokim gestem. Wypijasz kolejkę i wsiadasz po kwadransie w komunikację miejską.
Scenariusz drugi
Wsiadasz w komunikację miejską, pokonujesz n przystanków. Wysiadasz. Wchodzisz na klatkę i łomocesz do drzwi. Kolega otwiera, a na pytanie o wspólne picie mówi, że jeszcze od wczoraj mu nie zeszło. Mówisz
– To weź zadzwoń jak ogarniesz, OK?
– Dobra
Kolega dzwoni i jedziesz się napić.
Pierwszy scenariusz ssał, nie tylko jako sposób na życie, ale także jako metodologia. W podobny sposób zachowuje się wiele aplikacji klienckich.
- Odczekaj interwał
- Sprawdź, czy jest nowa poczta
- Jest? Jeśli jest, zapisz. Nie? Idziesz na start, nie otrzymujesz \$200.
W drugi przypadku mówimy o Push. Pewnie zauważyliście, że Wasz mądrytelefon albo tablet piszczy niecierpliwie natychmiast po otrzymaniu wiadomości? To dlatego, że serwer po otrzymaniu informacji, które są dla konkretnego klienta informuje go o tym fakcie. Nie ma więc interwału pomiędzy przychodzącą wiadomością, a „świadomością” klienta o tym fakcie.
Gdybyście projektowali jakąś prostą aplikację, gdzie jest wyraźny podział między częścią serwującą dane, a klientem możecie wprowadzić proste modyfikacje, które pozwolą Wam uniknąć tej całej komunikacji publicznej via TCP/IP.
Serwer powinien móc zapisać ścieżkę „do oddzwonienia” dla konkretnego klienta. Kiedy pojawia się nowa informacja, serwer opakowuje nowe dane i przesyła je do klienta, który może natychmiast zareagować. Przykładowy dialog:
– Klient: Dzień dobry, to moje dane autoryzacyjne
– Serwer: OK, widzę. Czego?
– K: Jak pojawi się coś dla mnie to zapamiętaj, że masz to wysłać na
http://bronikowski.com/flaszka/
S: Pamiętam. Idź już.
A potem:
– S: O, są nowe informacje o flaszkach, których wg dostępnych logów nie
słałem do klienta. Gdzie to słać? A, tam.
– K: O, dane!
Notkę napisałem głównie żeby się zawstydzić, bo znów zaprojektowałem coś, co robi Pull. Jestem leniwym i durnym draniem, ale to już wiedzieliście.