# Phar ... brilliant, a couple of questions?

- Thread: https://externals.io/message/38917
- Original archive: https://news-web.php.net/php.internals/38917
- Started by Jochem Maas on 2008-07-12T16:36:45+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #38917 — Jochem Maas — 2008-07-12T16:36:45+00:00

URL: https://externals.io/message/38917#38917

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?

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

---

## #38918 — Scott MacVicar — 2008-07-12T17:21:15+00:00

URL: https://externals.io/message/38917#38918 · In reply to: #38917

> 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

---

## #38923 — Jochem Maas — 2008-07-13T19:39:12+00:00

URL: https://externals.io/message/38917#38923 · In reply to: #38918

Scott MacVicar schreef:
> 
> 
> 
> > […]

...

> > […]
> 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.

I see, I think even readonly would be a real boon. in the case of readonly
mounting would it be possible to do read/write to an sqlite db file that
exists on the FS but is referenced via a 'symlink' in the Phar?

e.g. that code would reference phar://myphar/mydb.sqllite
and that the Phar ('myphar') has 'mounted' the file
/home/jochem/stuff/mydb.sqllite at phar://myphar/mydb.sqllite

this would allow a phar to self-extract it's DB if/when it
needs read/write access and reference the DB file in code at
the same path regardless of whether the DB file is actually inside
the Phar at the time.

this all assumes self modifying Phars are to be encouraged, which
given the leanings towards signed code, is probably not the case ...
a pity from a usability perspective ... I'd love to be able to
reduce the production file count down to 2 for small sites (the vhost.conf
& the .phar)

> 
> > […]

well am I? :-)

---

## #39027 — Greg Beaver — 2008-07-17T01:42:00+00:00

URL: https://externals.io/message/38917#39027 · In reply to: #38917

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