Comments on: PHP 5.3: de PHAR extensie

By: Alfa

Alfa — Wed, 27 Aug 2008 17:09:47 +0000

Heb de documentatie gelezen, maar nog niets gezien wat daarop wijst. Kan zijn dat dat nog niet gedocumenteerd is natuurlijk…

By: Maarten

Maarten — Wed, 27 Aug 2008 09:12:53 +0000

Dat moet haast wel mogelijk zijn, lijkt me 1 van de belangrijkste features. Lees: als daar niet over nagedacht is mag het direct een pijnlijke dood sterven.

By: Mathieu Kooiman

Mathieu Kooiman — Wed, 27 Aug 2008 09:04:13 +0000

@Alfa: Het is geloof ik ook nog mogelijk om externe toegang tot bepaalde 'directories' binnen het PHAR archief te weigeren.

By: Alfa

Alfa — Wed, 27 Aug 2008 08:10:25 +0000

@Mathieu Kooiman
ja, maar van een gemiddeld zend frameworkproject bijvoorbeeld is 95% van de bestanden buiten een webmap. Alleen je index.php + css + js is publiekelijk benaderbaar. Het is wel erg bewerkelijk om dat allemaal te mounten.

By: Mathieu Kooiman

Mathieu Kooiman — Wed, 27 Aug 2008 05:15:28 +0000

@alex: Precies. Het nut van PHAR is inderdaad niet helemaal duidelijk.

@Alfa: Nee, als je phar::mount() zo gebruikt dat je config files buiten het PHAR bestand wordt geplaatst, kun je er ook voor zorgen dat deze niet in de webroot staan.

By: Alfa

Alfa — Tue, 26 Aug 2008 19:39:10 +0000

Is een phar niet potentieel onveiliger? Wie de eigen app in een phar verpakt, moet de phar in een publieke directory zetten. Normaal gesproken zet je sommige delen (configuratie, bibliotheken) etc buiten de webmappen.

By: Alex Kamsteeg

Alex Kamsteeg — Tue, 26 Aug 2008 12:57:31 +0000

Dat had ik heus wel gezien, maar daarvoor moet ik wel cachen waardoor ik mijn server moet herstarten bij elke wijziging. Met wat geheugen erbij kan het hele filecaching gebeuren door het OS afgehandeld worden, waardoor ik mijn hele deployment procedure niet hoef te wijzigen.

By: Mathieu Kooiman

Mathieu Kooiman — Tue, 26 Aug 2008 10:16:18 +0000

@alex: Je leest toch over iets heen. De performance gaat, mits je de nodige maatregelen neemt, niet 'hard achteruit'.

By: Sebastiaan Stok

Sebastiaan Stok — Tue, 26 Aug 2008 08:24:34 +0000

Het kan handig zijn voor kleine command-line applicaties of achtergrond processen en wat PEAR doet een simpele installer, maar voor website zou ik het liever niet gebruiken.

phar is eigenlijk net zo iets als jar (java archief).

By: Alex Kamsteeg

Alex Kamsteeg — Tue, 26 Aug 2008 07:47:40 +0000

Eerlijk gezegd zie ik het nut niet zo. Wat maakt het voor je beheer uit of je 1 of 100 files via FTP upload? En als dat wel uitmaakt gooi je er een tar.gz of een zip op en pak je die op de commandline even uit. Bij een multi-server opstelling kan je heel eenvoudig met bijvoorbeeld Rsync de boel verspreiden vanaf een masterserver, dus dan is het ook geen argument.

Dan de performance, die gaat gewoon keihard achteruit. Als ik het allemaal goed begrijp wordt is het gewoon een soort zip-file waar je uit gaat zitten lezen, wat dus behoorlijk wat CPU power kost. Het enige voordeel is dat je random I/O afneemt, omdat je nu maar 1 file hoeft in te lezen, maar het verminderen van random I/O is over het algemeen al vrij eenvoudig op te lossen door meer geheugen in de server te zetten. Linux heeft bijvoorbeeld een uitstekende FS cache die prima werkt.

Voor beveiliging van je source hoef je het ook niet te doen. Er zit namelijk geen beveiliging in en dus valt dat ook al af.

Welke voordelen zijn er dan nog? Wat mij betreft geen of een paar hele kleintjes. Voor zover ik het nu kan zien is de PHAR extensie gewoon zonde van de moeite geweest.