Jochem Maas wrote:
[snip]
I have a few questions, some of the answers may deserve
a few lines in the docs.
1. to what extent is Phar capable/designed to handle self
updating Phars .. especially with regard to multi-user access
(I'm thinking in terms of a website+CMS+userdata in a Phar
updated by a few people 'concurrently')
This is a great question - it needs to be added to the phar FAQ in the
manual (which I suppose should be in the "using phar" section).
My best advice is this:
do not use phar if you want to write to the code or to files in the
code space.
phar archives should contain *only* read-only data and code. Your best
bet is to use a product designed for concurrency: a database.
Why? Imagine - every time you update a single file in a phar archive,
the whole archive must be rebuilt from scratch. This could take up to
60 seconds for large applications with 100s of megabytes of files. Not
fun even if you have 1 concurrent user.
2. is there a (quick) way to reference a Phar object of
the current (as in Phar::isRunning()) Phar file - I figure
the engine can do new Phar(Phar::isRunning()) faster/better, no?
in the stub, put this code:
$__myphar = new Phar(__FILE__);
and use $__myphar when you need it. Alternatively, you could do:
define('MYPHAR', __FILE__);
in the stub, and then when you need it:
$phar = new Phar(MYPHAR);
However, if you want to quickly access the contents of a single file
within the phar archive, use the streams layer:
For instance, if you know the path to the file, you can always do this:
$a = file_get_contents(__DIR__ . '/file.txt');
or even
$a = file_get_contents(__DIR__ . '/../file.txt');
3. are there technical reasons for not being able to create/access
an sqllite db inside a Phar?
As Scott said, we have talked about this and have a plan to implement
read-only sqlite, and also read-write if the database is external and
mounted using Phar::mount()
4. Am I crazy to think of building a dynamic website, cms, including
all user [uploaded] files, installation config .. complete with
command line interface for updates, upgrades, module/config
management, etc, etc ... all in one Phar? is that feasable?
what kind of read and/or write concurrency could one expect?
if building self updating Phars is okay, then maybe an example
in the manual could be done to emphasis a few do's, dont's,
limitations, etc.
No, you are not crazy. However, you must design so that uploaded files
are saved on the local filesystem, the configuration file is also saved
on the local filesystem, and a database is used for oft-referenced items
that need concurrency.
This is not so different from a regular PHP app - you have to set the
writable bit on upload directories, and do a little bit of config that way.
The only problem with Phar::mount() is that phar.cache_list is not
available (i.e., the instant you call Phar::mount(), copy-on-write
happens, which is a lot of memory copying), something that I need to
ponder when I have some time, as there may be a way around this
limitation that doesn't kill performance.
Personally, I would design the app so that it works without code change
in or out of a phar archive, which is actually not hard to do in PHP
5.3. Config items can be adjusted by checking whether Phar::running()
is 0-length, which it is if called outside of a phar archive.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
