W dniu 16.09.2011 22:28, Maciej Sobczak pisze:
> On Sep 16, 11:33 am, Michoo<m...@v...pl> wrote:
>
>>> To podej cie ma sens tylko wtedy, gdy b dzie istnia mniej lub
>>> bardziej otwarty rynek plugin w, czyli gdy u ytkownicy b d mogli
>>> pozyska pluginy niezale nie od Ciebie.
>>
>> Z tym si nie zgodz .
>> Ma to sen tak e wtedy, gdy r ni u ytkownicy b d u ywa r nych
>> podzbior w funkcjonalno ci dostarczanej przez jednego dostawc . Nie
>> trzeba wtedy dla ka dego z 50 klient w linkowa osobnej wersji
>> aplikacji, tylko wys a im odpowiedni zestaw plugin w (a nawet sami mog
>> sobie taki zestaw wyklika ).
>
> No właśnie - mogą sobie wyklikać. Tak, jak się klika
> konfigurację jądra dla Linuksa albo FreeBSD. 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.

>
> 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?


> 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 z drugiej strony nie ma problemu - możemy klientowi
dostarczyć na wstępie cały zestaw pluginów a potem aktywować je za
pomocą kluczy.


> 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.

>
> Natomiast jednego jestem pewny: jeżeli pozwolisz użytkownikom
> swobodnie ładować pluginy,
Tu nie chodzi o swobodne ładowanie a o wygodne z punktu widzenia
programisty zarządzanie podzbiorami funkcjonalności.

Można by powiedzieć, że kolejny krok w kierunku lepszej enkapsulacji.

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ą.

--
Pozdrawiam
Michoo