Komponenty mozilli, było: Mozilla (rc1) i java

[wrobell]

On Sun, Apr 21, 2002 at 10:50:57PM +0200, Tomasz Kłoczko wrote:
> On Sun, 21 Apr 2002, wrobell wrote:
> 
> > On Sun, Apr 21, 2002 at 09:33:50PM +0200, Tomasz Kłoczko wrote:
> > > On Sun, 21 Apr 2002, wrobell wrote:
> > > [..]
> > > > Tak więc zdanie "jedna ma włączone wsparcie do LDAP, a druga nie"
> > > > nie jest, o ile mi wiadomo dzisiaj, prawdziwe.
> > > 
> > > To było o tym co różni dwa spece dla tych pakietów.
> 
> > Gołym okiem  jest to  jedyna różnica. Jak  napisałem, diabeł
> > tkwi w szczegółach. Takie  same pliki różnią się zawartością
> > pomiędzy normalną  wersją i wersją embedded,  co powodowało,
> > że wersja embedded  działała gorzej. Tak było  w każdym bądź
> > razie dla wersji sprzed 0.9.8.
> 
> A wiesz może jak to teraz wygląda ?
> Jak znajdziesz czas o ile nie wiesz to prośba .. sprawdź (wiesz już
> co sprawdzać więc będzie Ci łatwiej niż komuś innemu :)
Na razie wolałbym się zająć tetexem w końcu. Obecnie dla mnie najważniejsza
jest mozilla-embedded ponieważ innych elementów mozilli nie używam. :-)
 
> I jeszcze jedno pytanie które mi się ciśnie. Otóż jak się popatrzy na
> wynik pmapa z galeona to wpadaja tam komponenty które de facto nie są
> użwyane w tej aplikacji. Dotyczy to np. libeditor.so (galeon nie wspiera
> edycji dokumenytów a powyższe można przypuszczać że ma związek z edycją
> .. ?).
libeditor.so to nie composer; jest to komponent, który umożliwia edycję
tekstu np.: w formularzach, a nie do tworzenia stron - o ile mi wiadomo

    http://www.mozilla.org/editor/


> Ciekawe czy gdyby w wydzielonym z pakiecie potrzebnym do
> działnia galeonowi nie było tego modułu czy kilku innych komponentów to
> czy galeon by zadziałał ?

    http://www.mozilla.org/projects/embedding/howto/WhatYouNeed.html

> Zja zadziała mozilla o ile tego modułu nie bedzie ? Będzie widoczna 
> pozycja w menu czy nie ? Jęzlei nie i całosć bezie od tego czy ten poduł 
> jest czy go nie ma to bezie mzoąn zrobic podpakiet typu 
> mozilla-component-editor (albo coś koło takiehgo). Jeżli będzie podobnie z 
> innymi komponntami to wydaje się że miałoby sens zrobienie całej serii 
> podpakietów mozilla-component-*.
Jest to na pewno dobra myśl. Część rzeczy mamy już wydzielone:
1. nspr (nspr.spec)
2. nss (nss.spec)
3. mozilla-mailnews (mozilla.spec) -> mozilla-mail ? mozilla-news ? mozilla-addressbook?
4. mozilla-embedded

Przydałoby się napewno jeszcze wydzielić mozilla-composer (do tworzenia stron)
i też mozilla-psm. To jest tak na początek. Później można myśleć o wydzielaniu
innej funkcjonalności.

> Z drugiej strony jeżeli w pmięć wpada komponent do edycji, a aplikacja
> edycji nie wspiera to coś musi decydować, że powinno być to załadowane i
> wygląda, że jest to nieporawna decyzja i/lub powiązania między modułami są
> sztywne, a cała modularyzacja jest iluzją. Sprawdzenie czy
> zasygnalizowanie tego ludziom od mozilli mogłoby też być ciekawe (Arek
> masz tu już jakieś kontakty .. spróbuj zagadnąć o to też :).
Część modułów na pewno musisz mieć (patrz link powyżej).

> No i kolejne pytanie które mi się jeszcze ciśnie jako konsekwencja
> powyższego to kiedy są ładowane te komponenty ?
> Czy przy starcie czy dopiero w momencie kiedy są potrzebne ? Wygląda że
> działa to przy starcie, a powinno być raczej kompletnie dynamicznie (wtedy
> kiedy jest to dopiero potrzebne). Jeżeli miało to działać dynamicznie to
> także pownno działać wyładowywanie modułów nieużywanych i zwalnanie przez
> nie zajmowanej pamieci. O ile ten mechaniz działałby poprawnie (a wygląda 
> że nie działa) to w ten sposób mogłoby się okazać, że na starcie jednak
> mozilla czy galeon zajmowałyby mniej pamięci i miałyby duże szanse
> utrzymanie odczuwalnie mniejszego zapotrzebowania na pamieć w trakcie
> dalszego działania.
> Tutaj sytuacja mogłaby bardzo prosto mieć związek z np. libcookie.so. O
> ile ktoś w konfiguracji ma zaznaczone że chce ignorować cookies to
> zagladając do pamieci apliakcji takiej jak mozilla czy galeon nie powinno
> się tam zobaczyć tego modułu (czyż nie ?).
> 
> Przykładowo w tej chwili u mnie z galeonem wygląda to tak:
> 
> $ pmap 24636 | tail -1
> mapped:   61728 KB writable/private: 34452 KB shared: 300 KB
> 
> co jak widac wcale małym kawłakiem pamieci nie jest, a potencjalnie przy
> lepszej gospodarce modułami mogłoby chyba to lepiej jednak wyglądać (?).
> 
> To tyle z wniosków jakie mi się tu nauwać jak dzisiaj się zacząłm temu
> przyglądać z pmapem w ręku.
Może i tak, ale to wymaga pewnego garbage collectora (co i kiedy wywalać?)
i może najzwyczajniej się nie opłacać ponieważ strony www korzystają z tak
wielu elementów (formularze, javascript, style, obrazki, ssl, itp.), że
wyrzucony z pamięci komponent za chwilę i tak będzie na nowo ładowany.

Oczywiście możliwe, że są elementy, które być może warto
ładować/nie ładować na starcie, ale moja propozycja jest taka, żeby
zuafać ludziom z mozilli. Obecnie zbliżają się do 1.0 i mają ważniejsze
rzeczy do zrobienia (obecne minimalne wymagania to 32MB, co dla większości
przypadków, nawet embedded wystarcza). W przyszłości podejrzewam, że
będą o bardziej dynamicznym ładowaniu modułów myśleć, jeśli już coś
takiego gdzieś im po głowach nie chodzi.

Zauważ też, że obecnie w projekcie mozilli istnieje dosyć mocne lobby, którego
celem jest umożliwienie _budowanie_ jedynie wybranych elementów mozilli.
Obecnie trzeba zbudować wszystko i zainstalować porzebne komponenty.

    wrobell <wrobell w ite.pl>