eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingAPI zdarzeniowe / sekwencyjne, push/pull jak to ożenić
Ilość wypowiedzi w tym wątku: 3

  • 1. Data: 2012-05-07 16:18:24
    Temat: API zdarzeniowe / sekwencyjne, push/pull jak to ożenić
    Od: Jacek Czerwinski <...@...z.pl>

    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?


  • 2. Data: 2012-05-07 19:54:52
    Temat: Re: API zdarzeniowe / sekwencyjne, push/pull jak to ożenić
    Od: A.L. <l...@a...com>

    On Mon, 07 May 2012 16:18:24 +0200, Jacek Czerwinski <...@...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.


  • 3. Data: 2012-05-08 09:34:02
    Temat: Re: API zdarzeniowe / sekwencyjne, push/pull jak to ożenić
    Od: Maciej Sobczak <s...@g...com>

    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

strony : [ 1 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: