Tekst over PHP interpreteren

[Benm]

Praktisch maakt het niet zoveel uit of een taal runtime gecompileerd wordt, of puur als script wordt afgehandeld. Uiteindelijk wordt php ook omgezet naar assemby instructies op de server, iedere keer als een pagina wordt opgevraagd opnieuw.

Qua interoperabiliteit is dit verder geen probleem - php code die draait in een linux hostingomgeving werkt ook prima in een windows omgeviing, al kan het wel zijn dat je bestandslocaties anders moet gaan definieren. Normaliter vergt dat niet meer dan een of andere variabele veranderen die verwijst naar de bestandslocatie, iets dat je ook zult ondervinden als je een php site wilt kopieren van de ene naar de andere linux host.

[Xenion]

Praktisch maakt het niet zoveel uit of een taal runtime gecompileerd wordt,

Jawel hoor: als je at runtime eerst nog moet 'compileren' voor je instructies kan uitvoeren dan ben je sowieso trager dan een programma dat al in machinetaal staat en meteen uitgevoerd kan worden.

Een groot voordeel van geïnterpreteerde talen is dat enkel de interpreter moet 'geport' worden naar verschillende platformen (Windows, Linux, ...). De ontwikkelaars van die scripts moeten daar dan geen rekening mee houden (behalve mss met de paden van files zoals jij aangeeft).

[Benm]

Daarom ook: praktisch

PHP is toch vooral een taal bedoeld voor websites, en bij het hele proces van een pagina opvragen, die genereren en weer naar de opvrager sturen is dat stukje runtime compilatie echt geen significante factor. Overigens is het best -mogelijk- om php te compileren en daarna van de gecompileerde code gebruik te maken, bijvoorbeeld met de Zend optimizer, eAccelartor en dergelijke. Dit wordt vooral gedaan om cpu load van de server te verminderen, maar het levert ook snelheidswinst op.

Het aardige is dat deze systemen vaak transparant werken: je blijft gewoon ontwikkelen in php en plaatst de bestanden ongecompileerd op de webserver. Die doet daar vervolgens de compilatie als je dat wilt, maar het is nooit een vereiste, de php code blijft ook gewoon werken op servers die niet compileren.

Voor PHP is dit absoluut een pluspunt: webservers zijn heel divers, tig verschillende linuxversies, windowsversies, allemaal andere hardware, wisselende webserver software (apache, lighthttpd etc). Een gecompileerde versie aanleveren voor ieder platform zou een ondoenlijke opgave zijn.

[Exception]

Nadeel van interpretatie talen is niet de tijd want vaak ervaar je dat verschil helemaal niet.

Maar je kan met deze talen je code niet beveiligen. Iedereen die toegang heeft tot dezelfde server kan jouw script stelen en de code van je database lezen. Tegenwoordig doen veel mensen aan hosting, ook amateurs. Als je iets leuks maakt, dan "stelen" ze het, en gaan ze het iets anders noemen, maar met dezelfde script.

Een beetje zoals javascript.

Of is dit geen nadeel?

[Bart]

Nadeel van interpretatie talen is niet de tijd want vaak ervaar je dat verschil helemaal niet.

Maar je kan met deze talen je code niet beveiligen. Iedereen die toegang heeft tot dezelfde server kan jouw script stelen en de code van je database lezen. Tegenwoordig doen veel mensen aan hosting, ook amateurs. Als je iets leuks maakt, dan "stelen" ze het, en gaan ze het iets anders noemen, maar met dezelfde script.

Een beetje zoals javascript.

Of is dit geen nadeel?

Je kunt PHP code alleen lezen vanaf de server zelf, niet via je browser. Dit in tegenstelling tot javascript, die wordt geïnterpreteerd door je browser en daarmee dus op de client machine komt te staan.

Als je je server goed beveiligd en zelf beheerd komt niemand bij de PHP code.

[Xenion]

Je eigen toegang tot de server is normaal gezien ook beperkt tot je eigen mappen. Andere klanten kunnen dus niet aan jouw data.

Wat betreft de eigenaar van de server: dat is een kwestie van vertrouwen. Er zijn waarschijnlijk ook wel wetten om je tegen zo'n praktijken te beschermen, maar van recht ken ik niks.

Denk er ook aan: als jij ergens een account aanmaakt dan kan het goed zijn dat je wachtwoord onversleuteld wordt opgeslagen. Iedereen die in de database van die website kan (de eigenaars of hackers), kan dan je wachtwoord zien.

[Benm]

Je kunt inderdaad de broncode lezen. Als je je hosting op een shared server hebt draaien dan kan het hostingbedrijf sowieso wel bij die code, en andere klanten daarvan alleen als er iets grondig mis is (leesrechten op andermans files).

Overigens is het wel een nadeel als je php programmatuur verkoopt: De klant kan de broncode lezen, en evt kopieren, al dan niet met aanpassingen erin. Dat kan vervelend zijn als je een onbetrouwbare klant hebt die aan de haal gaat me je software, al is dat uiteraard juridisch gezien gewoon verboden.

In zulke gevallen wordt nog wel eens gecompileerde code aangeleverd. Tools daarvoor zijn bijvoorbeeld Zend Encode en Ioncube. Nadeel is dat je specifiek moet gaan compileren voor een OS, en specifiek voor de php versie die draait. Als men upgraded naar een nieuwe php versie is er behoorlijke kans dat het systeem ermee stopt totdat je een nieuwe versie compileert.

[Exception]

Als men upgraded naar een nieuwe php versie is er behoorlijke kans dat het systeem ermee stopt totdat je een nieuwe versie compileert.

Dit stukje begrijp ik niet echt. Wat bijvoorbeeld in PHP1 werkt, werkt toch sowieso in PHP3?

[317070]

Dit stukje begrijp ik niet echt. Wat bijvoorbeeld in PHP1 werkt, werkt toch sowieso in PHP3?

Niet als het gecompileerde php is.

[Benm]

Inderdaad, de gecompileerde code is behoorlijk specifiek. Iets dat bijvoorbeeld gecompileerd is tegen php 5.2 zal waarschijnlijk niet werken onder php 5.3. Dit probleem heeft het altijd heel lastig gemaakt php programmatuur te distribueren zonder de brondcode vrij te geven. De enige tamelijk betrouwbare method is de zend encoder, maar dat is een prijzig stukje software.