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.

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

> Do tego dochodz takie "drobne" udogodnienia jak za adowanie nowego
> pluginu bez restartu aplikacji.

Niezależnie od tego jaki to jest program - od aplikacji desktopowej po
system w satelicie - swobodnie obstawiam, że częstość dołączania/
aktywacji nowych modułów jest mniejsza, niż średnia długośc sesji.
Czyli to udogodnienie, że niby można załadować nowy plugin bez
restartu aplikacji, to jest rozwiązywanie nieistniejącego problemu.
Oczywiście chętnie usłyszę jakiś przykładowy kontrargument, tylko
praktyczny.

Natomiast jednego jestem pewny: jeżeli pozwolisz użytkownikom
swobodnie ładować pluginy, to pewnego dnia dostaniesz takiego maila:

"Witam. Program mi znika natychmiast po uruchomieniu. Co robię źle?"

;-)

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