Not so long ago, it was proposed that we should have an PHP archive model
like Java does. I think it might me useful for application deployment.
Someone posted that PEAR::Config has this feature. I could find such
feature.
What was proposed is something like this:
File: application.php
<?
include_once ("classes/MyClass.inc.php");
$f = fopen("files/test.txt", "r");
...
?>
The archive my_application.par (could be an .zip, etc) would have these
three files inside:
application.php
classes/MyClass.inc.php
files/test.txt
And this standalone application is executed with:
php -p <package-file> <startup-script>
php -p my_application.par application.php
Since PHP already have an ZIP file extension and now the filesystem
functions have an improved abstraction layer, maybe it's time to think about
adding transparent ZIP support on this abstraction layer.
Cristiano Duarte.
Hello Cristiano,
Wednesday, August 6, 2003, 9:00:41 AM, you wrote:
CD> What was proposed is something like this:
CD> File: application.php
CD> <?
CD> include_once ("classes/MyClass.inc.php");
CD> $f = fopen("files/test.txt", "r");
CD> ...
?>>
CD> The archive my_application.par (could be an .zip, etc) would have these
CD> three files inside:
CD> application.php
CD> classes/MyClass.inc.php
CD> files/test.txt
CD> And this standalone application is executed with:
CD> php -p <package-file> <startup-script>
CD> php -p my_application.par application.php
CD> Since PHP already have an ZIP file extension and now the filesystem
CD> functions have an improved abstraction layer, maybe it's time to think about
CD> adding transparent ZIP support on this abstraction layer.
I think that should be great to have transparent ZIP layer at the
"include"/"require" level so one could write something like "require
'./lib/some-arc.par/SomePath/MyClass.php'"; but the command-line
interface imho should be similar to java i.e.
php -par my-app.par
And concrete info about app should locate in meta data file like jar's
meta-inf/manifest.mf because user executes application, not the script
'a.php' or 'b.php' ( application may consider this scripts are not for
execute by user ). Any info that he wants to provide to it should be
provided in command line.
But how will you differentiate between your par's dir and the dir where
archive is? I mean if you have par in directory
/home/me/php/my-app.par and in file
my-app.par/MyClass.php you write something like "require
'./SomeClass.php'" what file should be included? The
/home/me/php/my-app.par/SomeClass.php or /home/me/php/SomeClass.php?
If the first one is expected behavior how will you address the
filesystem beyond your archive, will you write something like "require
'../SomeClass.php'" for /home/me/php/SomeClass.php? Importing scheme
like java's one could solve this problem but it does not exist in PHP :(
--
Best regards,
Simeon mailto:xi@newmail.ru
I think that should be great to have transparent ZIP layer at the
"include"/"require" level so one could write something like "require
'./lib/some-arc.par/SomePath/MyClass.php'"; but the command-line
interface imho should be similar to java i.e.php -par my-app.par
Personally I would prefer bz2 - at least bzip2 is OpenSource.
And packages can be smthing like bcompiler's compiled code - obviously there is no need to change sources of such packages, so they could contain bytecodes.
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net
Antony Dovgal wrote:
I think that should be great to have transparent ZIP layer at the
"include"/"require" level so one could write something like "require
'./lib/some-arc.par/SomePath/MyClass.php'"; but the command-line
interface imho should be similar to java i.e.php -par my-app.par
Personally I would prefer bz2 - at least bzip2 is OpenSource.
And packages can be smthing like bcompiler's compiled code - obviously there is no need to change sources of such packages, so they could contain bytecodes.
The problem with bz2 is the lack of multiple files support. ZIP already
supports multiple files (like .tar.bz2).
If we can have native support for ".tar.bz2" I agree with your point of
view.
Cristiano Duarte.
Please, take it off this list.
----- Original Message -----
From: "Cristiano Duarte" cunha17@uol.com.br
To: internals@lists.php.net
Sent: Wednesday, August 06, 2003 5:23 PM
Subject: Re: [PHP-DEV] PHP archive
Antony Dovgal wrote:
I think that should be great to have transparent ZIP layer at the
"include"/"require" level so one could write something like "require
'./lib/some-arc.par/SomePath/MyClass.php'"; but the command-line
interface imho should be similar to java i.e.php -par my-app.par
Personally I would prefer bz2 - at least bzip2 is OpenSource.
And packages can be smthing like bcompiler's compiled code - obviously
there is no need to change sources of such packages, so they could contain
bytecodes.
The problem with bz2 is the lack of multiple files support. ZIP already
supports multiple files (like .tar.bz2).
If we can have native support for ".tar.bz2" I agree with your point of
view.Cristiano Duarte.
Wez Furlong wrote:
Please, take it off this list.
Excuse me? What's the matter?
Cristiano Duarte.
Simeon Koptelov wrote:
Hello Cristiano,
Wednesday, August 6, 2003, 9:00:41 AM, you wrote:
CD> What was proposed is something like this:
CD> File: application.php
CD> <?
CD> include_once ("classes/MyClass.inc.php");
CD> $f = fopen("files/test.txt", "r");
CD> ...
?>>
CD> The archive my_application.par (could be an .zip, etc) would have these
CD> three files inside:
CD> application.php
CD> classes/MyClass.inc.php
CD> files/test.txtCD> And this standalone application is executed with:
CD> php -p <package-file> <startup-script>CD> php -p my_application.par application.php
CD> Since PHP already have an ZIP file extension and now the filesystem
CD> functions have an improved abstraction layer, maybe it's time to think about
CD> adding transparent ZIP support on this abstraction layer.I think that should be great to have transparent ZIP layer at the
"include"/"require" level so one could write something like "require
'./lib/some-arc.par/SomePath/MyClass.php'"; but the command-line
interface imho should be similar to java i.e.php -par my-app.par
I agree.
And concrete info about app should locate in meta data file like jar's
meta-inf/manifest.mf because user executes application, not the script
'a.php' or 'b.php' ( application may consider this scripts are not for
execute by user ). Any info that he wants to provide to it should be
provided in command line.
I agree.
But how will you differentiate between your par's dir and the dir where
archive is? I mean if you have par in directory
/home/me/php/my-app.par and in file
my-app.par/MyClass.php you write something like "require
'./SomeClass.php'" what file should be included? The
/home/me/php/my-app.par/SomeClass.php or /home/me/php/SomeClass.php?
If the first one is expected behavior how will you address the
filesystem beyond your archive, will you write something like "require
'../SomeClass.php'" for /home/me/php/SomeClass.php? Importing scheme
like java's one could solve this problem but it does not exist in PHP :(
The precedente must be cleary defined. We must know if we have to search
inside the par file before or after searching the filesystem. IMHO the
par file must be searched first (for security reasons).
Maybe, we can store the par file structure in memory to speed the file
seaching.
Cristiano Duarte