Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.

 
Reply to this topicStart new topic
> PHP Archive czyli phar
mike
post 19.09.2008, 09:54:18
Post #1





Grupa: Przyjaciele php.pl
Postów: 7 494
Pomógł: 302
Dołączył: 31.03.2004

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post
batman
post 19.09.2008, 10:23:09
Post #2





Grupa: Moderatorzy
Postów: 2 913
Pomógł: 267
Dołączył: 11.08.2005
Skąd: 127.0.0.1




Dzisiaj rano znalazłem na RSS informację, że w PHP 5.3 ma pojawić się phar. Nie spotkałem się z tym wcześniej, więc temat mnie zainteresował. W telegraficznym skrócie chodzi o to, że będzie można tworzyć archiwa PHP wzorowane na archiwach jar, znanych z Javy.
Jak tylko poczytałem w manualu co to jest, przyszło mi do głowy kilka pomysłów. Między innymi to, że w końcu aplikacje pisane w PHP będzie można tworzyć modułowo (a nie prawie modułowo). Każdy z modułów będzie spakowany w takim właśnie archiwum, którego dołączenie będzie polegało na wrzuceniu go na serwer oraz dołączeniu w odpowiednim pliku.
Samo archiwum może zawierać oprócz plików PHP, inne pliki, np obrazki, dzięki czemu będzie można tworzyć gotowe do użycia paczki. Skończą się problemy polegające na dylemacie - gdzie i jakie pliki trzeba przenieść, by zastosowane zmiany na serwerze testowym zadziałały na produkcji.
Dobrze napisana aplikacja będzie składać się z kilku plików PHP oraz dołączonych do nich modułów. By zapewnić unikatowość nazw, wystarczy użyć przestrzeni nazw.


--------------------
I would love to change the world, but they won't give me the source code.
My software never has bugs. It just develops random features.
--------------------
blog
Kuchnia Kopytka
www.wykangurzeni.pl
Go to the top of the page
+Quote Post
starach
post 19.09.2008, 10:31:58
Post #3





Grupa: Zarejestrowani
Postów: 999
Pomógł: 30
Dołączył: 14.01.2007
Skąd: wiesz ?

Ostrzeżenie: (0%)
-----


Kolejny dowód na tezę że PHP zmierza nieustannie w kierunku Javy. I jest to plus moim zdaniem.
Nie bardzo jednak widzę sens używania tej biblioteki patrząc chociażby na PEAR.
Zgodnie z manualem PEAR używa tej biblioteki do instalacji ( nie doczytałem czy tylko samego siebie czy też modułów ).
Jednak biblioteki PEAR składowane są w postaci plików PHP i katalogów. Tak dobrze jest i nie widzę specjalnej potrzeby komplikowania tego.
Dodatkowo na niekorzyść może przemawiać iż przy dołączeniu pliku z takiego archiwum przy np. include('phar:///path/to/myphar.phar/file.php');
zanim plik zostanie dołączony musi on zostać wypakowany. Miałoby to jakiś większy sens przy serwerze aplikacji gdzie nie trzeba by było przy każdym wywołaniu uruchamiać tego procesu.

edit>
Istnieje już coś podobnego do Phar'a w niektórych systemach zarządzania treścią gdzie moduły i wtyczki dystrybuowane są na zasadzie spakowanych archiwów. Przy instalacji następuje rozpakowanie, a następnie instalator czyta plik xml i wykonuje odpowiednie zadania.

edit>>
OT: Wczoraj zainstalowałem Fedorę po czym olałem go(ją?). Jestem zdania że PHP rozwija się w 10 razy szybszym tempie niż ten system.
Pewnie wedle zasad rachunku prawdopodobieństwa ... coś w końcu musi winksmiley.jpg

Ten post edytował orglee 19.09.2008, 10:47:41
Go to the top of the page
+Quote Post
mike
post 19.09.2008, 10:47:40
Post #4





Grupa: Przyjaciele php.pl
Postów: 7 494
Pomógł: 302
Dołączył: 31.03.2004

Ostrzeżenie: (0%)
-----


~orglee no właśnie to nie działa tak jak myślisz. Odwołanie się do czegokolwiek wewnątrz archiwum (phar lub jar) nie powoduje wypakowania czegokolwiek. Archiwum takie jest po prostu przezroczystym dostępem do zawartości.

Piszesz, że coś już jest. No właśnie jest to coś innego. W przypadku paczek instalujesz a ona się sama rozpakowuje. W przypadku takiego archiwym po prostu wklejasz plik w jedno mieksce i koniec. Nic nie rozpakowujesz.
Go to the top of the page
+Quote Post
starach
post 19.09.2008, 10:51:27
Post #5





Grupa: Zarejestrowani
Postów: 999
Pomógł: 30
Dołączył: 14.01.2007
Skąd: wiesz ?

Ostrzeżenie: (0%)
-----


Skoro tak to faktycznie może to być nie głupia opcja.
I nie piszę że już coś jest tylko że jest to mechanizm podobny. Nie podoba mi się tylko konieczność rozpakowania archiwum żeby coś zmodyfikować,
no ale wtedy może programiści PHP zaczną z głową pisać swoje skrypty i będzie można w naszych korzystać z dobrodziejstw dziedziczenia.

W takim razie jestem za. Pomysł nie jest głupi.
Go to the top of the page
+Quote Post
batman
post 19.09.2008, 10:57:08
Post #6





Grupa: Moderatorzy
Postów: 2 913
Pomógł: 267
Dołączył: 11.08.2005
Skąd: 127.0.0.1




Cytat(orglee @ 19.09.2008, 11:51:27 ) *
...Nie podoba mi się tylko konieczność rozpakowania archiwum żeby coś zmodyfikować...

Tak samo jest w Javie (chyba, że się mylę, niech Javowcy mnie poprawią). Poza tym nie będzie problemów z "przypadkowym" zmodyfikowaniem jakiegoś pliku, ponieważ najpierw trzeba będzie go rozpakować.

Widzę już oczami wyobraźni, jak W PDT można tworzyć phar tak samo prosto, jak uruchomić kompilator, np Javy winksmiley.jpg


--------------------
I would love to change the world, but they won't give me the source code.
My software never has bugs. It just develops random features.
--------------------
blog
Kuchnia Kopytka
www.wykangurzeni.pl
Go to the top of the page
+Quote Post
Albitos
post 19.09.2008, 17:26:56
Post #7





Grupa: Zarejestrowani
Postów: 37
Pomógł: 4
Dołączył: 6.08.2006
Skąd: Lublin

Ostrzeżenie: (0%)
-----


Z tego co czytałem dostęp do treści w archiwach PHAR nie będzie wolniejszy. W przypadku kodu PHP mozliwe jest sformatowanie go w taki sposób, aby działał nawet szybciej! Przynajmniej tak czytałem tutaj: http://www.zyxist.com/pokaz.php/phar_pear_pyrus


--------------------
Albi's Jogger - z pamiętnika młodego programisty
Orodlin Team Member
Go to the top of the page
+Quote Post
wrzasq
post 20.09.2008, 21:03:53
Post #8





Grupa: Zarejestrowani
Postów: 206
Pomógł: 18
Dołączył: 6.03.2006
Skąd: Szczecin

Ostrzeżenie: (0%)
-----


PHAR mi sie troche nie podoba, o wiele bardziej za to spodobał mi się PHK - http://phk.tekwire.net/. Przede wszystkim dlatego, ze generuje pliki PHP, ktore mozna tak po prostu rozprowadzac (pliki .phar moza uruchomic jedynie, gdy w PHP aktywne jest rozszerzenie PHAR)! Nie mam teraz czasu szerzej opisac swoich doswiadczen, w kazdym razie tworzac niektore biblioteki (na przyklad PHP OTServ Toolkit) jakos znacznie latwiej mi sie pracowalo z PHK. Aczkolwiek nic nie stoi na przeszkodzie (zazwyczaj) generowania obydwu rodzajow archiwow.

Chcialbym tylko wskazac bardzo przydatna moim zdaniem opcje obslugi roznego trybu uruchamiania - zarowno PHK jak i PHAR daja nam mozliwosc dodania skryptow startowych do naszych paczek i to osobnych dla tryby strony WWW, osobnym dla urunamiania z linii komend (CLI), oraz z tego co pamietam jeszcze kilka innych trybow, na przyklad informacyjny.


--------------------
Go to the top of the page
+Quote Post
mike
post 20.09.2008, 21:26:38
Post #9





Grupa: Przyjaciele php.pl
Postów: 7 494
Pomógł: 302
Dołączył: 31.03.2004

Ostrzeżenie: (0%)
-----


Cytat(wrzasq @ 20.09.2008, 22:03:53 ) *
Przede wszystkim dlatego, ze generuje pliki PHP, ktore mozna tak po prostu rozprowadzac (pliki .phar moza uruchomic jedynie, gdy w PHP aktywne jest rozszerzenie PHAR)!
Z wersją PHP 5.3 nic nie będziesz musiał doinstalowywać. APhar będzie częścią core'a PHP.
Go to the top of the page
+Quote Post
misiek172
post 25.09.2008, 17:02:02
Post #10





Grupa: Zarejestrowani
Postów: 656
Pomógł: 3
Dołączył: 26.10.2005
Skąd: Częstochowa

Ostrzeżenie: (0%)
-----


Na logikę to archiwum PHAR będzie po prostu jak zwykły folder, tylko troszeczkę w wygodniejszej formie, dobrze zrozumiałem?
Ogółem podoba mi się taka opcja, ponieważ będzie ona przymuszać programistę do pisania bardziej uniwersalnych skryptów, aby dało się to archiwum wszędzie dołączyć.


--------------------
zmoderowano - waga i rozmiar
Go to the top of the page
+Quote Post
Mchl
post 25.09.2008, 21:49:17
Post #11





Grupa: Zarejestrowani
Postów: 855
Pomógł: 145
Dołączył: 17.07.2008
Skąd: High Memory Area

Ostrzeżenie: (0%)
-----


A czy widział już ktoś, jak wygląda taki phar od środka?
Czy jest to jakiś sposób, żeby ukryć kod przed użytkownikiem?
Go to the top of the page
+Quote Post
Zyx
post 27.09.2008, 17:44:39
Post #12





Grupa: Zarejestrowani
Postów: 952
Pomógł: 154
Dołączył: 20.01.2007
Skąd: /dev/oracle

Ostrzeżenie: (0%)
-----


Domyślnie plik PHAR jest zwykłym skryptem PHP, w którym w pewnym miejscu pierdyknięte jest wywołanie pseudofunkcji __halt_compiler() - dalej jawnie leci treść kolejnych "spakowanych plików". Odczyt odpowiedniego podpliku sprowadza się na ustawieniu kursora w miejscu jego rozpoczęcia i rozpoczęcia kompilacji skryptu od tego miejsca. API Phar-a może też posłużyć do tworzenia archiwów TAR, a także kompresji samych pharów.

Żeby zapakować skrypt do postaci Phar, w zasadzie nie trzeba przerabiać istniejących skryptów - w sieci widziałem już np. phpMyAdmina w wersji Phar. Jedyny dodatek to skrypt pakujący smile.gif.

Phar przyda się twórcom bibliotek - do każdego archiwum można dołączyć tzw. "stub", który jest wywoływany w momencie załadowania archiwum. Można tam dać np. procedury inicjacyjne, jak np. rejestrowanie autoloadera biblioteki czy wstępną konfigurację.

Albitos -> Trochę przekręciłeś tę notkę smile.gif. Miałem na myśli, że twórcy PHP mogą optymalizować PHAR-a, zmniejszając liczbę odwołań dyskowych (w sensie: jest to wykonalne i być może tak będzie). Na dzień dzisiejszy sytuacja wygląda tak, że skrypty uruchamiane z Pharem i bez niego działają praktycznie tak samo szybko (różnice są rzędu pojedynczych żądań na 1000). Niestety, póki co kiepsko współpracuje toto z optymalizatorami kodu. Po włączeniu APC, Phar jest wyraźnie wolniejszy. Mail odkrywający ten fakt można znaleźć tutaj: http://marc.info/?l=php-internals&m=12...3624673&w=2


--------------------
Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0
Go to the top of the page
+Quote Post
motylo
post 13.10.2008, 14:24:49
Post #13





Grupa: Zarejestrowani
Postów: 35
Pomógł: 5
Dołączył: 13.07.2008
Skąd: Kalisz

Ostrzeżenie: (0%)
-----


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 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 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.


--------------------
Więcej: blog.juszczak.org
Go to the top of the page
+Quote Post
Zyx
post 13.10.2008, 15:18:01
Post #14





Grupa: Zarejestrowani
Postów: 952
Pomógł: 154
Dołączył: 20.01.2007
Skąd: /dev/oracle

Ostrzeżenie: (0%)
-----


Uruchamiając archiwum phar nie ładujemy znajdujących się tam plików do pamięci. Uruchamiany jest wyłącznie stub i to on ewentualnie decyduje, czy nie dołączyć jednego z elementów archiwum.


--------------------
Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0
Go to the top of the page
+Quote Post
bigZbig
post 21.10.2008, 18:23:15
Post #15





Grupa: Zarejestrowani
Postów: 740
Pomógł: 15
Dołączył: 23.08.2004
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Cytat(misiek172 @ 25.09.2008, 18:02:02 ) *
...
Ogółem podoba mi się taka opcja, ponieważ będzie ona przymuszać programistę do pisania bardziej uniwersalnych skryptów, aby dało się to archiwum wszędzie dołączyć.

Programista do niczego nie zostanie zmuszony, a już na pewno nie do pisania bardziej uniwersalnego kodu. Problem z modułowością aplikaci też nie zostanie do końca rozwiązany bo zawsze w takich sytuacjach pojawia się kwestia zależności tak jak to ma miejsce w PEAR. Ale żeby nie być takim sceptykiem wspomnę, że widzę w tym rozszerzeniu szansę na lepsze mechanizmy dystrybuowania aplikacji a także ich aktualizację.


--------------------
bigZbig (Zbigniew Heintze) | blog.heintze.pl
Go to the top of the page
+Quote Post
qbatoja
post 20.11.2008, 00:16:15
Post #16





Grupa: Zarejestrowani
Postów: 52
Pomógł: 0
Dołączył: 3.05.2005

Ostrzeżenie: (10%)
X----


phar - nic specjalnego. plusow wielu nie widze, poza jednym zarabistym (wyzej pare razy wspomniany) - aktualizacja.
Swego czasu w jednej agencji interaktywnej obslugiwalem firme axa ubezpiecznia, pajace nie chcieli nam dac dostepu do serwera i pliki ktore zmienialismy, wysylalismy im mailem i oni wrzucali na swoj serwer. wiele razy dzwonili do nas, bo nie wiedzieli gdzie plik x wrzuc a gdzie plik z. nie wazne ze instrukcje dostawali.
w przypadku pharow, dostaja jeden plik i po sprawie.
BTW: oczywiscie nie jestem zwolennikiem pharowania core aplikacji.
Go to the top of the page
+Quote Post
ucho
post 9.02.2010, 11:01:21
Post #17





Grupa: Zarejestrowani
Postów: 300
Pomógł: 32
Dołączył: 31.07.2006

Ostrzeżenie: (0%)
-----


Pozwolę sobie odgrzebać temat. Ktokolwiek tego wynalazku używa? Nie widziałem jeszcze na oczy żadnej biblioteki, która była by w tej postaci dystrybuowana.
Go to the top of the page
+Quote Post
Crozin
post 9.02.2010, 15:15:01
Post #18





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


Z tego co widzę to użytkownik Zyx chyba z tego korzysta: http://www.invenzzia.org/en/download
Go to the top of the page
+Quote Post
Zyx
post 10.02.2010, 15:05:18
Post #19





Grupa: Zarejestrowani
Postów: 952
Pomógł: 154
Dołączył: 20.01.2007
Skąd: /dev/oracle

Ostrzeżenie: (0%)
-----


PHAR jest wykorzystywany chociażby w projekcie PEAR2, który ma zastąpić obecne repozytorium PEAR. Można też znaleźć wiele opisów, jak zapakować do tej postaci rozmaite aplikacje (phpMyAdmin, Zend Framework itd.). Problem z brakiem oficjalnych paczek może wynikać z tego, że twórcy chcą zachować kompatybilność z wcześniejszymi wersjami PHP, które PHAR-a nie obsługują bądź nie mają.


--------------------
Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0
Go to the top of the page
+Quote Post
webdice
post 10.02.2010, 15:13:33
Post #20


Developer


Grupa: Moderatorzy
Postów: 3 045
Pomógł: 290
Dołączył: 20.01.2007




Cytat(ucho @ 9.02.2010, 11:01:21 ) *
Pozwolę sobie odgrzebać temat. Ktokolwiek tego wynalazku używa? Nie widziałem jeszcze na oczy żadnej biblioteki, która była by w tej postaci dystrybuowana.


Korzystam z tego w kilku projektach, ale tylko na serwerach dedykowanych, gdzie mam taką możliwość. Na chwile jest to głównie zabawa z archiwami, ale szczerze mówiąc jest w tym potencjał.

Projektów na chwile obecną nie wypuszcza się jako archiwum, z jednego prostego powodu, po prostu większość serwerów nie ma w kompilowanego modułu phar.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 16.12.2019 - 05:58