Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38918
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error)
Cc: php internals <internals@lists.php.net>
Message-ID: <A6FC0D3B-0E22-4A7C-8026-FD820CF3C56F@macvicar.net>
To: Jochem Maas <jochem@iamjochem.com>
In-Reply-To: <4878DD9D.2030409@iamjochem.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Date: Sat, 12 Jul 2008 13:21:15 -0400
References: <4878DD9D.2030409@iamjochem.com>
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  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. :) > > 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. [...]
	Content analysis details:   (-4.4 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
Subject: Re: [PHP-DEV] Phar ... brilliant, a couple of questions?
From: scott@macvicar.net (Scott MacVicar)


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. :)
>
> 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
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Scott