Właśnie pracuję nad programem, który po dotarciu do wersji alfa podzielę
na moduły. Zanim zacznę męczyć kwestię modułów to chciałbym poznać
opinie innych. Do rzeczy :)

Program będzie miał obecnie jeden moduł, w przyszłości dojdą
kolejne(oby). Jak to bywa przy projektach, tworzony jest
framework/szkielet aplikacji. Aplikacja będzie tworzona w Qt 4.7 i
obecnie przychylam się takiemu rozwiązaniu:

* framework(klasy bazowe, managery obiektów itp.) będzie biblioteką
dynamiczną,

* moduł(moduły) będzie zaimplementowane za pomocą mechanizmu
pluginów z Qt.

Sam malutki program będzie składał się z okna głównego i np. dialogu
logowania oraz będzie ładował dll od frameworka, jeśli będą dostępne
pluginy modułów, to wtedy będzie rysowany interfejs od modułu. Moduły
będą też korzystały z dll frameworka(zawiera bazowe, więc chyba musi).

Myślałem by zrobić z frameworka bibliotekę statyczną, ale po
zastanowieniu stwierdziłem że to wymagałoby wielokrotnego wkompilowania
tegoż frameworka w program oraz w każdy moduł. Mogłoby to generować
problemy, które trzeba by było zapewne żmudnie debugować. Framework jako
biblioteka dynamiczna pozwala na to żeby wszystko co związane z
programem(aplikacja + moduły) korzystały z dokładnie tej samej
biblioteki(przez co chyba nie będzie problemu z korzystania np. z
singletona z frameworka w pluginach i aplikacji). Dobrze kombinuję czy
może gdzieś widzicie luki, bądź jakieś inne rozwiązania? No i na koniec
duże byłoby udogodnienie jeśli chodzi o testowanie z wykorzystaniem
QTestLib(które chciałbym właśnie zacząć wykorzystywać przy okazji
rozdzielenia aplikacji na biblioteki i pluginy).

Pozdrawiam i czekam na opinie - przychylne jak i nie.
Łukasz

do góry

W dniu 15.09.2011 15:12, Lukasz pisze:
> * framework(klasy bazowe, managery obiektów itp.) będzie biblioteką
> dynamiczną,
>
> * moduł(moduły) będzie zaimplementowane za pomocą mechanizmu pluginów z Qt.
>
Aplikację, którą pisałem na razie miałem w kilku bibliotekach
dynamicznych. Zdziwiłem się jak dobrze to działało zarówno pod win jak lin.

Aplikacja, którą niedługo będę robił (migracja projektu używającego java
webstart) będzie prawdopodobnie składać się z małego loadera (który
będzie m.i. sprawdzał czy jest pobrana najnowsza wersja) i biblioteki
dll z całą zawartością (+ ewentualne pluginy zależnie od potrzeb).


--
Pozdrawiam
Michoo

do góry

W dniu 15.09.2011 23:58, Michoo pisze:
> Aplikacja, którą niedługo będę robił (migracja projektu używającego java
> webstart) będzie prawdopodobnie składać się z małego loadera (który
> będzie m.i. sprawdzał czy jest pobrana najnowsza wersja) i biblioteki
> dll z całą zawartością (+ ewentualne pluginy zależnie od potrzeb).
>

Czyli dobrze myślę by brnąć w tą stronę? Też właśnie mam zamiar
zastosować aktualizator - zamiast instalować kilku megowego patcha, będą
pobierane pojedyncze pliki. Chciałbym też spróbować zachować binarną
kompatybilność, by nie było potrzeby rekompilacji innych
bibliotek/aplikacji.

do góry

W dniu 2011-09-16 00:31, Lukasz pisze:
> W dniu 15.09.2011 23:58, Michoo pisze:
>> Aplikacja, którą niedługo będę robił (migracja projektu używającego java
>> webstart) będzie prawdopodobnie składać się z małego loadera (który
>> będzie m.i. sprawdzał czy jest pobrana najnowsza wersja) i biblioteki
>> dll z całą zawartością (+ ewentualne pluginy zależnie od potrzeb).
>>
>
> Czyli dobrze myślę by brnąć w tą stronę? Też właśnie mam zamiar
> zastosować aktualizator - zamiast instalować kilku megowego patcha, będą
> pobierane pojedyncze pliki. Chciałbym też spróbować zachować binarną
> kompatybilność, by nie było potrzeby rekompilacji innych
> bibliotek/aplikacji.

Jeśli zależy Ci na modułowości tylko ze względu na małe patche, to
może poszukaj czegoś o patchowaniu binarnym, szczególnie do plików
wykonywalnych?

--
Paweł Kierski
n...@p...net

do góry

On Sep 15, 3:12 pm, Lukasz <k...@a...pl[usun]> wrote:

> Sam malutki program będzie składał się z okna głównego i np. dialogu
> logowania oraz będzie ładował dll od frameworka, jeśli będą dostępne
> pluginy modułów, to wtedy będzie rysowany interfejs od modułu.

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.
Jest na to parę dobrych przykładów, od przeglądarek www po edytory
wszelkich możliwych materiałów.
Natomiast jeśli przewidujesz, że to Ty będziesz autorem wszystkich
części - zarówno rdzenia jak i pluginów - to daj sobie spokój z ddlami
i linkuj wszystko statycznie, nawet jeśli chcesz oferować użytkownikom
różne zestawy pluginów. Dzięki temu będziesz miał większą kontrolę nad
spójnością programu i zaoszczędzisz na późniejszym supporcie.

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

do góry

W dniu 16.09.2011 09:06, Maciej Sobczak pisze:
>
> 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ć).
Do tego dochodzą takie "drobne" udogodnienia jak załadowanie nowego
pluginu bez restartu aplikacji.

--
Pozdrawiam
Michoo

do góry

W dniu 2011-09-16 11:33, Michoo pisze:
> W dniu 16.09.2011 09:06, Maciej Sobczak pisze:
>>
>> 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ć).
> Do tego dochodzą takie "drobne" udogodnienia jak załadowanie nowego
> pluginu bez restartu aplikacji.
>

Jeśli pominiesz problem dystrybucji nieco większej binarki i nie
obawiasz się hackowania (użycia pluginów, których dany klient miał
nie móc użyć), to dystrybucja statycznie zlinkowanego klocka +
konfiguracja per klient nadal jest lepsza. Binarkę budujesz raz,
a zarządzasz tylko konfiguracjami.

--
Paweł Kierski
n...@p...net

do góry

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

do góry

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

do góry

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

do góry