On Sep 17, 5:02 pm, Michoo <m...@v...pl> wrote:

> > Co jak zamawianie pizzy
> > - wybierasz sk adniki a pizzaiolo przy piekarniku lepi wszystko tak
> > jak sobie wybra e . Nie widz tu problemu z linkowaniem statycznym.
>
> Ja te nie widz specjalnego problemu - albo pakujemy wybrane pliki .so,
> albo gcc na wybranych plikach .a.

Wolę wersję statyczną. Przynajmniej wiadomo, że użytkownik niczego
ręcznie nie pomieszał.

> > Praktykuje si r wnie inne podej cie - wszystko zlinkowa co si da i
> > dostarczy klientowi ca y produkt, ale tylko niekt re jego modu y s
> > aktywne, reszta jest nieaktywna i aktywuje si j p niej.
>
> Tylko co w sytuacji gdy nie da si tego zlinkowa bo mamy plugin X i
> jego wersj dla firm A,B r ni ce si kilkoma szczeg ami, kt rych
> wprowadzenie do mainline nie jest ani celowe ani korzystne?

Nie rozumiem. Czego się nie da zlinkować? Różnych modułów? Pewnie, że
się da.
A to, że coś nie jest celowe, to nikogo nie obchodzi, jeśli niechciane
części są nieaktywne.

> > Wad jest
> > to, e si bierze wi kszy pakiet na pocz tku ale zalet jest to, e
> > p niejsza aktywacja modu w w og le nie musi nawet wymaga po czenia
> > przez net. I to si praktykuje, nawet cz sto.
>
> Ale te aktualizacja wymaga konstruowania binarnych at albo pobierania
> ca o ci na nowo, nie mo na wys a po prostu zmodyfikowanej jednej
> biblioteki.

A co za różnica?
Jak na swoim komputerze widzę, że jest aktualizacja do jakiegoś
programu, to mnie kompletnie nie interesuje, czy to jest łata, czy
całość, czy 4 z 156 bibliotek. Widzę tylko, że jest aktualizacja i
mogę wcisnąć Continue albo i nie wcisnąć.
Użytkownika naprawdę nie interesuje w jakim formacie te aktualizacje
przyjdą.

> > Oczywi cie ch tnie us ysz jaki przyk adowy kontrargument, tylko
> > praktyczny.
>
> Za my, e mamy aplikacj obs uguj c kilkaset da na minut . W
> przypadku odpowiednio rozwi zanego systemu plugin w mo emy oznaczy
> plugin jako przeznaczony do wy adowania(zostanie wy adowany gdy sko cz
> si wszystkie po czenia), za adowa now wersj i mie aktualizacj bez
> downtime.

Widziałeś już coś takiego w praktyce? Nazwa produktu, please.

BTW - co to znaczy "gdy skończą się wszystkie połączenia" i czym to
się różni od downtime?

BTW2 - a co jak się połączenia nie skończą, bo zawsze przyjdzie jakieś
nowe i nigdy nie będzie ich zero? Trzeba zrobić jakiś mechanizm, który
nie pozwoli na stworzenie nowych połączeń. I czym *to* się różni do
downtime z punktu widzenia tego odrzuconego klienta?

Gdybym miał zrobić taki hot-swap, to nie robiłbym programu jako zbioru
bibliotek, bo to na 100% się kiedyś wywali na hazardach, tylko jako
zbiór osobnych programów połączonych przez jakiś message bus w postaci
lokalnego brokera. Albo przewidziałbym failover pomiędzy instancjami
od samego początku. Takie coś robiłem i bez żadnego downtime'u można
było uaktualniać nie tylko software ale i hardware. Ale ładowanie i
wyładowywanie bibliotek w czasie działania programu? Science fiction.

> Przyk ad:
> w pewnej, rzadkiej sytuacji modu A u ywa foo z modu u B, foo zostaje
> zmodyfikowana (dzia a teraz w spos b niekompatybilny) i dopiero na
> etapie szczeg owych test w (albo dopiero w praniu) wychodzi zale no
> A->B. Gdyby to by y pluginy to komunikowa y by si po swoich publicznych
> interfejsach i by oby wiadomo od pocz tku, e specyfikacja foo jest jego
> sk adow .

Ale biblioteki dzielone kompletnie nic tu nie wnoszą. Wystarczy
posłużyć się narzędziami dostępnymi na poziomie języka. Jeśli one nie
wystarczają, to język jest do bani i biblioteki dzielone nadal nic tu
nie wniosą.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com