Béton brut

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.

  1. Odczekaj interwał
  2. Sprawdź, czy jest nowa poczta
  3. 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.

QR for Jedni pchają, inni ciągną