🚀 go-pugleaf

On Mon, 07 May 2012 16:18:24 +0200, Jacek Czerwinski <x@y.z.pl> wrote:

>Mam pewien problem, doraźnie już go sobie rozwiązałem, ale chętnie 
>przyjmę ogólniejsze idee.
>
>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)
>
>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 ...
>
>Rozwiązanie 'brutal force' sobie zbuforuje wszystko, ale bym oczekiwał 
>zajętości RAM mniej niż liniowej (doktoranci nie złościcie się na te słowa)
>
>Java, ale szukam czegoś ogólnego, bardziej wzorca, idei niż gotowca kodu.
>
>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.
>
>Może (idea mglista) wątki i synchronizacja?

Zapoznaj sie z paradygmatem "linda". W Javie to-to jest zrealizowane
jako JavaSpaces. Komercyjnie jako GigaSpaces. Moze byc overkill, ale
bardzo efektywne

A.L.

On May 7, 4:18 pm, Jacek Czerwinski <x...@y.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