PHP Archive czyli phar Opcje

[mike]

W związku z zainteresowaniem (i wnioskiem ~batmana) zakładam wątek.
Tytułem uzupełnienia napiszę tylko, że wątek ten jest miejscem dyskusji na temat biblioteki Phar.

[motylo]

Tematykę PHP Archive śledzę już od kilku lat (bodajże 3). Na początku powstało na bazie PEARa i w międzyczasie pojawiło się również w PECLu (gdzie przez długi okres czasu nie było aktualizacji - myślałem że projekt 'umarł'). Mimo podobnego nazewnictwa pliki końcowe miały odmienną budowę. Pokrótce można powiedzieć, że jeden dało się rozpakować zipem a drugi nie (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) . Bardzo ciekawym rozwiązaniem było zaszyfrowanie (w PEAR) pliku uruchomieniowego poprzez bibliotekę BLENC i następnie złączenie wszystkiego w jeden plik. Dzięki temu można było tworzyć zaszyfrowane pliki PHP. Aktualnie nie sprawdzałem różnic między najnowszymi wersjami z PECLa i PEARa.

Na dzień dzisiejszy, tj wersja PHP 5.2.x trudno znaleźć dużo informacji na temat PHARów (niedopracowany manual); opisy na dodatkowych stronach są zagmatwane i trzeba się troszeczkę namęczyć. Winą męczarni są różnice w składniach między poszczególnymi wersjami. I mimo, że na stronie będzie napisane "How to PHAR..." nie wiadomo czy tyczy się to PECLa czy też PEARa i której wersji.

Co do użyteczności - przydadzą się do tworzenia plików dystrybucyjnych (aktualnie tak z nich korzystam). Mając przykładowo klasę db z dziećmi, tworzymy paczkę db.phar; validate z regułami też jeden plik. Można dołączać dowolny rodzaj plików; jednakże przy większych paczkach zauważalny jest spadek prędkości wykonywania skryptów. I teraz po modyfikacji jakiejś klasy rozsyłamy po klientach, bądź wgrywamy tylko jeden duży plik. No i należy dodać, że ładnie to wygląda (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .

Można spakować, lub stworzyć archiwum. Do wyboru przy pakowaniu GZ lub BZ, można wybrać które pliki pakujemy i w jakim stopniu. Z biblioteki wielkości 900k czystego kodu zrobiło pliki o sumarycznej wielkości 120k.
Nie należy tworzyć jedej paczki do wszystkiego, ale podzielić na mniejsze, względnie tematyczne - nie zawsze użyjemy klasę którą zaincludujemy poprzez uruchomienie jednego pliku PHAR - powoduje to wzrost zajętości RAMu, dlatego idealnym rozwiązaniem jest właśnie utworzenie kilku a nawet kilkunastu takich plików (sprawdzone empirycznie).

Zgadzam się z wrzasq - lepszym rozwiązaniem może być PHK, i tutaj pojawia się kolejny problem świata PHP - wiele różnych rozwiązań, brak tego dobrego; mogliby połączyć siły. Mimo zaimplementowania w 5.3 PHARa, wątpie by wszyscy administratorzy zmienili wersję PHP na nowszą.

Podsumowując krok w bardzo dobrym kierunku, oprócz skąpej dokumentacji nie mam innych uwag.