Phar nie jest nowym wymysłem, gdyż działa on sprawnie już na PHP 5.2, z tym że trzeba go samodzielnie zainstalować z repozytorium PECL. Jako że wczoraj dorobiłem się najnowszej wersji rozwojowej interpretera, postanowiłem się trochę tym wszystkim pobawić.
Działanie Phar
Phar umożliwia zarówno załadowanie całego archiwum naraz, jak też wczytanie pojedynczego pliku:
require('./archiwum.phar'); // 1 require('phar://archiwum.phar/plik.php'); // 2
Rozszerzenie dodaje własną nakładkę strumieni (dla popolskuniekumających: stream wrapper), który umożliwia właśnie bezpośredni dostęp do zawartości archiwów poprzez zwykłe funkcje plikowe.
Każde archiwum posiada tzw. stub działający mniej więcej jak bootloader w systemie operacyjnym. Jest on uruchamiany, kiedy ładujemy całe archiwum (linijka 1), co oczywiście nie oznacza, że PHP przeparsuje wszystkie zawarte w nim pliki. W stubie możemy umieścić np. inicjację autoloadera biblioteki lub w przypadku gotowego skryptu, uruchomienie MVC.
Archiwa Phar mogą być także uruchamiane bezpośrednio przez interpreter, np. po wpisaniu adresu URL do przeglądarki lub z linii komend:
php archiwum.phar
W Internecie można łatwo znaleźć przykłady istniejących aplikacji spakowanych jako Phar (np. phpMyAdmin).
PHP nie udostępnia gotowego narzędzia do pakowania archiwów, a obiektowe API, które może także służyć do manipulowania plikami TAR i ZIP. Aby zapakować jakąś aplikację, musimy napisać dla niej skrypt pakujący, co nie jest specjalnie trudnym zadaniem i nawet w dokumentacji można znaleźć kilka przykładów.
Wydajność
Twórcy PHP robią, co mogą, by maksymalnie zoptymalizować działanie archiwów Phar. Odpowiednio napisane, mogą one znacząco zredukować ilość operacji dyskowych będących najczęściej wąskim gardłem. Drugi kierunek zmagań to integracja z systemem cache'owania kodu APC. Póki co nie wszystko wygląda rewelacyjnie, ale pożyjemy, zobaczymy. Na liście dyskusyjnej jednego z twórców PHP można znaleźć post, którego autor pokusił się o przetestowanie spakowanego phpMyAdmina. Wynika z niego, że w normalnych okolicznościach wydajność wersji niespakowanej i spakowanej jest prawie identyczna. Różnica to ułamek procenta na korzyść pierwszej. Sprawy mają się gorzej, gdy autor odpalił APC. Tutaj już normalna wersja lekko zdystansowała Phar. Przedstawiana na jakiejś konferencji miesiąc wcześniej prezentacja rysowała sprawę wydajności w znacznie czarniejszych barwach, więc albo udało im się znacząco poprawić kod, albo po prostu była to kwestia wybranej do testu aplikacji.
PHK
W repozytorium PECL siedzi jeszcze jedno rozszerzenie do obsługi tutejszego odpowiednika JAR-ów. Mowa jest o PHK, którego archiwa są niekompatybilne z Phar. Rozszerzenie to działa już na PHP 5.1 i ma tę zaletę, że nie musi być fizycznie zainstalowane, aby PHP był w stanie uruchomić wygenerowane przez niego archiwum, choć wtedy wydajność jest znacznie słabsza. Zgodnie z informacjami na stronie autora, sprawuje się ono gorzej, kiedy próbujemy wyciągnąć z archiwum pojedynczy plik, lecz posiada znacznie większe możliwości, gdy mówimy o uruchomieniu całej paczki. Twórca ponadto chwali się wsparciem trzech systemów cache'owania kodu, które tutaj faktycznie mają sprawiać, że spakowana aplikacja działa wtedy szybciej, niż niespakowana. Ile w tym jest prawdy, powiedzieć nie mogę, gdyż rozszerzenia nie miałem już czasu przetestować (zresztą, nawet Phara póki co tylko pobieżnie liznąłem. Niestety, jego dokumentacja nie jest jeszcze kompletna i do części rzeczy trzeba dochodzić metodą prób i błędów).
Dystrybucja kodu
Wraz z premierą PHP 6, projekt będzie mieć prawie kompletny system dystrybucji kodu, w skład którego wejdą:
- System archiwów Phar
- System cache'owania kodu APC
- Nowy instalator PEAR2: Pyrus
- Zaawansowany mechanizm autoloaderów
- Przestrzenie nazw
- Repozytorium PECL
Do kompletu brakowałoby tylko kompilatora Bytecode. Sztuką jednak będzie zgranie tych wszystkich narzędzi, by potrafiły one wzajemnie wykorzystać swoje możliwości. Do premiery PHP 6 być może uda się to zrealizować, gdyż na razie jeszcze różnie z tym bywa.
Całość nie odniesie jednak sukcesu, jeśli twórcy nie zrobią świetnej dokumentacji i nie będą dbać o promocję swoich narzędzi. Ile osób wie, że Symfony, Zend Framework, ez Components i wiele innych bibliotek może być zainstalowanych za pomocą PEAR, chociaż wcale one częścią tego repozytorium nie są? Ile osób próbowało samodzielnie założyć własny kanał dystrybucyjny dla swojego projektu? Ile osób wie, jak pisać kod PHP, by APC potrafił go przyspieszyć? Pewnie niewiele, skoro sami twórcy na listach dyskusyjnych mówią, że sposób informowania o tym jest, łagodnie mówiąc, do bani. W ramach eksperymentu zajrzałem do dokumentacji PEAR, by sprawdzić, jak mogę założyć własny kanał np. dla Open Power Libs. Oczywiście, był tam developer guide... w którym autorzy szeroko rozwodzili się o zasadach przyjmowania pakietów do PEAR, budowie pliku package.xml, zasadach kodowania, a o tym, że w ogóle można tego używać do czegoś innego niż PEAR, wspominał mimochodem fragment JEDNEGO ZDANIA: "or third party channels".
Jak to powinno być zrobione
Twórcy powinni zacząć od rozdzielenia dokumentacji. Jedna dotyczyłaby ogólnie samego instalatora, tworzenia pakietów, zakładania kanałów i wszystkiego, co chciałby widzieć twórca biblioteki lub programu. PEAR nie byłby w niej w żaden sposób wyróżniony, co oczywiście nie przeszkadza, by sam instalator był w tym napisany. Dopiero druga dokumentacja skupiałaby się na tym konkretnym repozytorium: zasady przyjmowania pakietów, standardy kodowania, czyli rzeczy, które w innych projektach mogą wyglądać inaczej.
Druga rzecz to uporządkowanie samej dokumentacji PHP. Przyznam szczerze, po tym, jak jej autorzy pogrupowali rozszerzenia tematycznie, za jasną cholerę nie potrafię tam nic odnaleźć :). Byłoby to jeszcze do zgryzienia (w końcu znam bezpośrednie adresy URL do wszystkich potrzebnych mi rozdziałów), gdyby nie fakt, że niektóre rzeczy po prostu nie są udokumentowane. Widać nie tylko ja borykam się z tym, że prawie nikt nie chce mi przy dokumentowaniu OPL pomóc, o tłumaczeniu już nie wspominając. Sama dokumentacja powinna być też wyznacznikiem pewnych reguł pisania, by programiści nie musieli wynajdywać koła na nowo. Sprowadza się to do zaproponowania schematu, który można by później łatwo powielić, przy okazji wiedząc, dlaczego jest to zrobione tak, a nie inaczej.
Zakończenie
Ufff, ale mi wyszedł długi wpis. Przydałoby się przynajmniej połowę przetłumaczyć na angielski i posłać twórcom, wraz ze wszystkimi pozytywnymi komentarzami, które by się poniżej pojawiły. W końcu ciężko oczekiwać zmian od kogoś, kto nie ma pojęcia, że ktoś inny ich oczekuje :).
Napisał Lucas w sobotę, 2 sierpnia 2008 o 15:45
Muszę przyznać że z dokumentacją masz całkowitą rację :) Pamiętam że jak pierwszy raz po zmianach zajrzałem w poszukiwaniu czegoś o PDO myślałem że mnie trafi. Na całe szczęście jest .chm w którym to niestety brak komentarzy. I kwestia porozbijania niektórych działów. Zwłaszcza o stringach wygląda to fatalnie. O ile gdy ktoś zna już php nie jest to problemem ale dla początkujących istna masakra.