Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38923
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <487A59E0.50104@iamjochem.com>
Date: Sun, 13 Jul 2008 21:39:12 +0200
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Scott MacVicar <scott@macvicar.net>
CC: php internals <internals@lists.php.net>
References: <4878DD9D.2030409@iamjochem.com> <A6FC0D3B-0E22-4A7C-8026-FD820CF3C56F@macvicar.net>
In-Reply-To: <A6FC0D3B-0E22-4A7C-8026-FD820CF3C56F@macvicar.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Phar ... brilliant, a couple of questions?
From: jochem@iamjochem.com (Jochem Maas)

Scott MacVicar schreef:
> 
> On 12 Jul 2008, at 12:36, Jochem Maas wrote:
> 
>> 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. :)

...

>>
>> 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.

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)

> 
>>
>>
>> 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.

well am I? :-)