-
Data: 2012-05-08 09:34:02
Temat: Re: API zdarzeniowe / sekwencyjne, push/pull jak to ożenić
Od: Maciej Sobczak <s...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]On May 7, 4:18 pm, Jacek Czerwinski <x...@...z.pl> wrote:
> Producent danych jest w modelu zdarzeniowym i dane by podawał dalej w
> modelu push.
>
> Ostateczny konsument danych ma coś jakby bardziej pull (oczekuje danych
> z iteratora i o dziwo znana długość). Opcjonalne API (mniej mi pasuje)
> oczekuje List bez jakiś udziwnień (mam nadzieję przetwarza je czystym
> studenckim algorytmem bez skakania po długości)
Tu pojawia się ogólny pomysł na generyczną listę (a raczej kolejkę),
do której z jednej strony można na bieżąco dopychać dane a z drugiej
iterować. W zasadzie jest to zwykła kolejka z iteratorem, którego
hasNext()/next() jest wrapperem na blokującą operację get() z kolejki.
Nie ma na to gotowca?
> Po drodze algorytm dodatkowy, trzeba wychwycić zmiany tych danych, w
> którym polu nastąpiła zmiana i choćby przez to pojawia się buforowanie
> niewielkiej ilości danych ...
Jakie zmiany? Skąd się te zmiany biorą? Czy pod tym pojęciem kryje się
fakt, że producent (ten, co to robi push) może opublikować to samo
kilka razy? Co to znaczy "to samo"? Jak są te dane identyfikowane?
Klucze jakieś? Jeśli tak, to skąd się tu bierze koncepcja listy, czyli
liniowej kolejności? Może raczej powinna to być mapa? Itd.
No i rozpruł się worek z problemami... ;-)
> Java, ale szukam czegoś ogólnego, bardziej wzorca, idei niż gotowca kodu.
Wzorzec nazywa się iterator. Realnym przykładem takiego iteratora jest
input stream iterator z C++, który ma te dwie główne cechy: nie musi
mieć wszystkich danych w pamięci i może się synchronizować z fizycznym
źródłem danych, którym może być choćby fizyczna kolejka FIFO, gdzie
faktycznie jest gdzieś jakiś producent (być może inny proces) robiący
push.
Czyli koncepcyjnie nic nowego - oprócz tego "drobiazgu" z
wychwytywaniem zmian.
> Może iść tym tropem List'y - taka wirtualna lista która udostępnia
> interfejs ale nie posiada na stałe tego 0.5GB danych, gdzieś w środku
> niech się ten push męczy.
No przecież napisałem.
> Może (idea mglista) wątki i synchronizacja?
Wątki i synchronizacja to potencjalny detal wynikający ze sposobu w
jaki te dane są przekazywane. W przykładzie z kolejką FIFO powyżej nie
są wymagane (system wszystko zrobi), w innym przykładzie z brokerem
komunikatów wątki zapewni broker. Wątki mogą być potrzebne tylko
wtedy, jeśli będziesz chciał komunikację między producentem i
konsumentem zrobić ręcznie - i tu, zależnie od rozmachu, można
pomyśleć o czymś gotowym.
--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
Najnowsze wątki z tej grupy
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
Najnowsze wątki
- 2024-12-23 Riga => Specjalista ds. public relations <=
- 2024-12-23 Łódź => Specjalista ds. Sprzedaży <=
- 2024-12-23 Kraków => International Freight Forwarder <=
- 2024-12-23 Co nalezy do Cinkciarza, a co do Conotoxia ?
- 2024-12-23 Poznań => Key Account Manager <=
- 2024-12-23 Warszawa => Presales / Inżynier Wsparcia Technicznego IT <=
- 2024-12-23 Rzeszów => Spedytor Międzynarodowy <=
- 2024-12-23 Warszawa => Infrastructure Automation Engineer <=
- 2024-12-23 Białystok => Analityk w dziale Trade Development (doświadczenie z Po
- 2024-12-23 Warszawa => Site Reliability Engineer (SRE) <=
- 2024-12-23 Warszawa => DevOps Engineer <=
- 2024-12-23 Warszawa => Senior Account Manager <=
- 2024-12-23 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-12-23 Katowice => Administrator IT - Wirtualizacja i Konteneryzacja <=
- 2024-12-23 Mińsk Mazowiecki => Spedytor Międzynarodowy <=