My OperaAcid2: Co się wydarzyło na linii Webcore - KHTML?
Friday, May 20, 2005 8:27:01 PM
Miałem o tym napisać już jakiś czas temu, ale niespecjalnie udawało mi się wykrzesać motywację 
Teraz widząc mity, jakie narosły wokół całej tej sytuacji nadrabiam zaległości. Wróćmy do początku.
Otóż jak zapewne wielu z Was się orientuje, Apple swego czasu wybrał jako bazę do budowy własnej firmowej przeglądarki silnik KHTML, który jest rozwijany przez zespół KDE i jest opoką, na której stoi przeglądarka Konqueror. Ten entuzjastycznie przyjęty wybór obudził głębokie nadzieje na to, że nareszcie rozwój silnika KHTML ruszy z kopyta. Wszak do pracy nad nim zaprzęgnięto wielu wysokiej klasy programistów firmy Apple. Jednak rzeczywistość okazała się szara i nieciekawa.
Apple ma dostęp do repozytoriów i bugzilli KDE. Natomiast w zamian programiści KDE otrzymują jedynie od czasu do czasu spakowane archiwa ze źródłami silnika, który tak naprawdę coraz mniej przypominał KHTML. Apple nazwał go Webcore. Owe archiwa zawierają tony zmian pomiędzy poszczególnymi wersjami, których normalny człowiek nie jest w stanie prześledzić i często, gęsto bywało tak, że gdy ktoś z teamu KDE chciał przeportować odpowiednie poprawki Apple z Webcore do KHTML, kosztowało go to więcej pracy niż własna autorska implementacja. Dlatego coraz rzadziej pojawiały się włączenia patchy autorstwa Apple.
Znamiennym przykładem tego zjawiska jest wsparcie dla właściwości text-shadow pochodzącej ze standardu CSS 2.0 Safari jest pierwszą przeglądarką, która wprowadziła obsługę tej właściwości. To fakt niezaprzeczalny, natomiast nie jest prawdą jakoby programiści KHTML włączyli tylko kod Webcore za to odpowiedzialny do źródeł KHTML. Programiści KDE zaprogramowali absolutnie niezależnie i zdecydowanie lepiej niż to jest obecne w Safari obsługę tej właściwości. Ale o tym wiedzą nieliczni.
Powszechna jest natomiast fama jakoby KHTML jest na garnuszku Apple'a. Atmosfera wokół tej sprawy niespodziewanie zgęstniała i urosła do masy krytycznej w czasie, gdy Dave Hyatt opracował ostatnie poprawki, które sprawiły, że Safari stała się pierwszą przeglądarką poprawnie obsługującą test Acid2 i które zostały publicznie udostępnione.
Natychmiast po tym fakcie pojawiły się żądania szybkiego włączenia tych łat do kodu KHTML. Wtedy to Zack Rusin, wylewając kubeł zimnej wody na rozemocjonowane głowy użytkowników Konquerora, stwierdził, że prawdopodobnie patche Hyatta nigdy nie zostaną przeportowane do KHTML z uwagi na opisywane wyżej zjawiska, które spowodowały, że rozdźwięk pomiędzy obydwoma gałęziami silników stał się zbyt duży i niemożliwy od ogarnięcia i jednocześnie z goryczą przypomniał co jest tego powodem.
Na szczęście firma Apple, dbająca o dobry PR, postanowiła zmienić ten stan rzeczy. Doszło do spotkania pomiędzy czołowymi programistami obu teamów na IRC-u, gdzie rozpoczęto ustalanie zasad wzajemnej współpracy. Wierzę, że zmieni to wzajemne relacje z obopólną korzyścią
To tyle co chciałem na ten temat rzec. Jak widać z tego jest kompletną nieprawdą jakoby Dave Hyatt chaotycznie łatając Safari, byle tylko ta przeglądarka pierwsza mogła prawidłowo wyrenderować Acid2, popsuł kod Webcore, za co dostał połajankę od zespołu KDE, którzy dzięki temu nie mogli w szybko włączyć patchy do kodu KHTML. Natomiast prawdą jest, że Ben Goodger, jeden z ojców Mozilli Firefoxa, ni z gruszki ni z pietruszki wciął się między wódkę i zakąskę, udzielając reprymendy teamowi KDE. Ci oczywiście nie pozostali mu dłużni i szybko opublikowali listę faktów, które Goodger raczył pominąć w swoich rozważaniach.
Teraz widząc mity, jakie narosły wokół całej tej sytuacji nadrabiam zaległości. Wróćmy do początku.
Otóż jak zapewne wielu z Was się orientuje, Apple swego czasu wybrał jako bazę do budowy własnej firmowej przeglądarki silnik KHTML, który jest rozwijany przez zespół KDE i jest opoką, na której stoi przeglądarka Konqueror. Ten entuzjastycznie przyjęty wybór obudził głębokie nadzieje na to, że nareszcie rozwój silnika KHTML ruszy z kopyta. Wszak do pracy nad nim zaprzęgnięto wielu wysokiej klasy programistów firmy Apple. Jednak rzeczywistość okazała się szara i nieciekawa.
Apple ma dostęp do repozytoriów i bugzilli KDE. Natomiast w zamian programiści KDE otrzymują jedynie od czasu do czasu spakowane archiwa ze źródłami silnika, który tak naprawdę coraz mniej przypominał KHTML. Apple nazwał go Webcore. Owe archiwa zawierają tony zmian pomiędzy poszczególnymi wersjami, których normalny człowiek nie jest w stanie prześledzić i często, gęsto bywało tak, że gdy ktoś z teamu KDE chciał przeportować odpowiednie poprawki Apple z Webcore do KHTML, kosztowało go to więcej pracy niż własna autorska implementacja. Dlatego coraz rzadziej pojawiały się włączenia patchy autorstwa Apple.
Znamiennym przykładem tego zjawiska jest wsparcie dla właściwości text-shadow pochodzącej ze standardu CSS 2.0 Safari jest pierwszą przeglądarką, która wprowadziła obsługę tej właściwości. To fakt niezaprzeczalny, natomiast nie jest prawdą jakoby programiści KHTML włączyli tylko kod Webcore za to odpowiedzialny do źródeł KHTML. Programiści KDE zaprogramowali absolutnie niezależnie i zdecydowanie lepiej niż to jest obecne w Safari obsługę tej właściwości. Ale o tym wiedzą nieliczni.
Powszechna jest natomiast fama jakoby KHTML jest na garnuszku Apple'a. Atmosfera wokół tej sprawy niespodziewanie zgęstniała i urosła do masy krytycznej w czasie, gdy Dave Hyatt opracował ostatnie poprawki, które sprawiły, że Safari stała się pierwszą przeglądarką poprawnie obsługującą test Acid2 i które zostały publicznie udostępnione.
Natychmiast po tym fakcie pojawiły się żądania szybkiego włączenia tych łat do kodu KHTML. Wtedy to Zack Rusin, wylewając kubeł zimnej wody na rozemocjonowane głowy użytkowników Konquerora, stwierdził, że prawdopodobnie patche Hyatta nigdy nie zostaną przeportowane do KHTML z uwagi na opisywane wyżej zjawiska, które spowodowały, że rozdźwięk pomiędzy obydwoma gałęziami silników stał się zbyt duży i niemożliwy od ogarnięcia i jednocześnie z goryczą przypomniał co jest tego powodem.
Na szczęście firma Apple, dbająca o dobry PR, postanowiła zmienić ten stan rzeczy. Doszło do spotkania pomiędzy czołowymi programistami obu teamów na IRC-u, gdzie rozpoczęto ustalanie zasad wzajemnej współpracy. Wierzę, że zmieni to wzajemne relacje z obopólną korzyścią
To tyle co chciałem na ten temat rzec. Jak widać z tego jest kompletną nieprawdą jakoby Dave Hyatt chaotycznie łatając Safari, byle tylko ta przeglądarka pierwsza mogła prawidłowo wyrenderować Acid2, popsuł kod Webcore, za co dostał połajankę od zespołu KDE, którzy dzięki temu nie mogli w szybko włączyć patchy do kodu KHTML. Natomiast prawdą jest, że Ben Goodger, jeden z ojców Mozilli Firefoxa, ni z gruszki ni z pietruszki wciął się między wódkę i zakąskę, udzielając reprymendy teamowi KDE. Ci oczywiście nie pozostali mu dłużni i szybko opublikowali listę faktów, które Goodger raczył pominąć w swoich rozważaniach.
You must be 
Zbigniew BranieckiGandalf1 # Friday, May 20, 2005 8:27:01 PM
Quiris, wybacz, ale mam nadal poczucie, ze Twoja wiedza na ten temat jest zbyt mala by sugerowac takie rzeczy. Widziales ten kod? To obejrzyj, najlepiej zanim zdecydujesz sie znow pouczac.
Marek Stępieńmarcoos # Friday, May 20, 2005 8:27:01 PM
Apple ma pełne prawo robić z KHTML/Webcore co im się żywnie podoba, dopóki to jest zgodne z licencją LGPL (tak samo jak AOL ma absolutne prawo przerobić Firefoksa na g*wno pt. "Netscape 8", dopóki trzyma się MPL).
Jeśli współpraca między Apple a KDE się nie układała, tak, jak sobie to KDEowcy wymarzyli, to powinni wcześniej próbować coś w tej sprawie zrobić, a nie pozwolić jej się gotować pod przykryciem, by wykipiała.
Zbigniew BranieckiGandalf1 # Friday, May 20, 2005 8:27:01 PM
Natomiast to, ze Apple podsylalo od zawsze patche w formie po prostu bzdurnej, np. 2 mb patcha z ostatnich 2 miesiecy, albo podsylali patche z Obj C, ktore oczywiscie jest MacOSX, to juz zakrawalo na zlosliwosc. Teraz sie okazalo, ze nie bylo to zlosliwoscia, ale frustracja w ludziach z KDE rosla.
Zastanow sie, ja Ty bys sie czul, jakbys dostawal takie cos, co mozna nazwac "ochlapem", a ktory wymaga czasem niezwykle duzo pracy (zadnych dokumentacji, logow patchy, nic, 2mb diffa z dwoch miesiecy pracy...) zeby cokolwiek z tego skorzystac.
Robert Błautquiris # Friday, May 20, 2005 8:27:01 PM
Wybacz, ale mam na tyle wiedzy by zrozumieć:
<a href="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008054">http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008054</a>
oraz:
<a href="http://www.kdedevelopers.org/node/view/1001">http://www.kdedevelopers.org/node/view/1001</a>
Zauważ o czym jest mowa. Mowa nie jest o tym, żeby Hyatt poszedł do szkoły uczyć się programowania, tylko o tym o czym inni pisali i o czym ja przypominam, bo zdaje się, że zupełnie wypaczyłeś sens tego co się wokół sprawy Apple/KDE dzieje.
Robert Błautquiris # Friday, May 20, 2005 8:27:01 PM
Wybacz marcoos, ale Goodger odnosi się wprost do cytowanej wypowiedzi Rusina, który IMO kozgorączkowanym byle fanem KDE nie jest, choć możliwe, że zaczął na Apple bluzgać
W stuprocentach zgadzam się. Dlatego w swojej wypowiedzi nie demonizowałem Apple, bo nie mogę tego robić w obliczu faktów prawnych.
O ile dobrze pamiętam to od początku ta współpraca nie była różana
Robert Błautquiris # Friday, May 20, 2005 8:27:01 PM
Zgadza się.
Dokładnie.
Marek Stępieńmarcoos # Friday, May 20, 2005 8:27:01 PM
Zbigniew BranieckiGandalf1 # Friday, May 20, 2005 8:27:01 PM
Tak. Akurat o tym pisali na blogach... Ja zas mowilem o czym innym. Nie wiem czemu skupiasz sie w odpowiedzi na udowadnianiu mi, ze byly rowniez inne powody i problemy na linii Apple - KDE.
Poza tym nie oskarzam nikogo o niski poziom kodowania. Hyatt jest swietnym profesjonalista, ktory przez wiele lat programowal dla Mozilli i jego kod jest swietny, ale w duzych projektach nie tylko umiejetnosci programisty wplywaja na jakosc patchy i wynik. Chocbys byl programistycznym Bogiem, kazdy wiekszy patch bedzie mial na poczatku liczne bledy i dlatego najlepiej, zeby patch byl dlugo testowany i sprawdzany przez wiele osob... A to wymaga czasu.