Phar ... brilliant, a couple of questions?

to Greg and his cohorts a hearty bravo!

Phar is a really great addition, I'm very impressed with
the finesse of the initial implementation ... it's quite
rare to see [imho] a new feature appear in such a mature
and well thought out manner, good work 'smith. :)

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')

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?

3. are there technical reasons for not being able to create/access
   an sqllite db inside a Phar?
   I have plans to add support to the various SQLite extensions to some
   extent, I've yet to see how much is possible.

If creating a VFS driver for sqlite is simple then they'll be full
read / write support else it will be mounting and read only.

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.

kind regards,
Jochem

--

Scott

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