wuch + twin ale jak ?

[Paweł Kołodziej]

Witam.
Troche dokładniej (ale wciąż nie bardzo dokładnie) przyjżałem się
twin'owi. Poniżej zamieszczam przemyślenia na temat "nowego" wucha.
Były by fajnie jakbyście rzucili na to krytycznym okiem, i jeśli potrzeba
zmieszali poniższe z błotem.

Wucha zdekomponujemy na duzo większa liczbe modółów niż obecnie:
 - core - modół "systemowy". W nim program spędza większość czasu (w
   oczekiwaniu że user coś zrobi), steruje pracą pozostałych
 - selektor pakietów (nie pokazujący informacji o pakietach, a jedynie 
   umożliwiający ich zaznaczenie na wiele sposobów).
 - wyświetlarka informacji -- wyświetla info o aktualnie podświetlonym
   pakiecie w selektorze
 - control center -- menu z którego user wybiera jaką chce podjąć akcję
   (instalacja zaznaczonych pakietów (czy raczej "ustalenie listy
   zainstalownych pakietów zgodnie z wyborem w selektorze (obejmuje
   instalacje i kasowanie pakietow); wysylanie raportu z ocena pakietu itp. ).
 - moduły do pobierania statystyk i wysyłania raportów
 - modół "ftp" do którego odwołują się pozostałe gdy potrzeby jest jakiś
   plik z sieci.
 - inne. właściewie dowolne. W tej chwili nie jest to istotne.

Na razie proponuje się ograniczyć do programu jedno wątkowego, ale tak
wszystko projektować aby uwielowątkowienie było możliwie proste.

Teraz najważniejsze: przepływ danych.
1. Informacje o zainstalowanych i dostępnych pakietach mogą być dostępne
   tak jak teraz w globalnej tablicy. Zamiast pola "selected" trzeba będzie
   zrobić bardziej ogólne flagi. Zmiany w tej tablicy dokonywane przez
   moduły wymagają wysłania stosownego broadcastu (patrz pkt. 3).
2. Komunikacja twin -- wuch będzie nadzorowana przez modol "core".
    Algorytm miej więcej taki:
    - msgport=CreateMsgPort;
    - w nieskonczonej petli:
       msg=ReadMsg(wait=1)
       rozpoznanie ktorego okna (modułu) dotyczy "msg" (informacja jest
       zapisana w stukturze opisującej zdazenie).
       modul[odpowiedniModol].processMsg(msg);
    - koniec petli
3. Komunikacja miedzy modulami.
   Kazdy modol moze wyslac "broadcast" gdy zaszła w nim zmiana na którą
   powinny zareagować inne moduły (np. w selektorze zmienił się
   podświetlony pakiet -> wysyłamy o tym informacje żeby modół z okienkiem
   z informacjami o pakiecie mógł się dostosować). Funckja powiedzmy
   SendBroadcast jest udostępniana przez modół core który rozsyła tą
   informacje do pozostałych modółów (wywołuje ich funkcje
   processBroadcast() ). Obsługę modułu ftp też można tak załatwić: jakis
   modól wysyłą broadcast "potrzebuje plik aaaa z ftp", mdól ftp go zciąga i
   wysyła broadcast "plik aaaa z ftp jest dostepny jako plik xxx na lokalnym
   dysku"
   Do póżniejszej dyskusji zostawiam format takich
   broadcastów (tekstowy, binarny -- chyba binarny ze względu na szybkosc,
   ale i tak jeszcze zostają szczegóły do dogadania).

Ze względu na ewentualną wilowątkowść (potrzebujemy jej ?) najbardziej
kłopotliwy wydaje się pkt. 1. 
To chyba tyle na dziś. 
       

PS. wiem miałem napisać za kilka dni, ale nie mogłem się powstrzymać.

-- 
Paweł Kołodziej 
pawelk w pld.org.pl 
,,O ile nam wiadomo, komputer nigdy nie popełnił niewykrytego błędu.''
                                                 -- Weisert