Re: Phar ... brilliant, a couple of questions?
| From: | Jochem Maas | Date: | Sun, 13 Jul 2008 19:39:12 +0000 |
| Subject: | Re: Phar ... brilliant, a couple of questions? | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-38923@lists.php.net to get a copy of this message | ||
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. :)
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)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.
well am I? :-)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.