Re: [RFC] Starting 5.3
| From: | David Coallier | Date: | Mon, 07 May 2007 18:54:15 +0000 |
| Subject: | Re: [RFC] Starting 5.3 | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-29285@lists.php.net to get a copy of this message | ||
On 5/7/07, Antony Dovgal <antony@zend.com> wrote:
On 05/07/2007 10:39 PM, Stanislav Malyshev wrote:are both useful (If you need more detailed examples (file names, etc I can also draw up something) 1) Phar: You can use phar for instance if you deploy all your own scripts, etc. A normal application without third party libraries bundled (Otherwise of couse you can store your third script in your phar and just make a new release when the third-script updates) etc. The idea of the phar is to make it easy to deploy. Which is good. 2) Pear: Pear has channels which make it really easy to deploy applications that are depending on different channels (third party scripts) which make it easy to both install and udpate. You wrap your application in your package name which you distribute through the SOMENAME.com channel, then you can also use another channel (the third party script) by using channel-discover and download/easy update the third-party scripts using pear upgrade SOMEOTHERCHANNEL.com's package name. -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18I guess we are solving the wrong problem. We have: 1. phar needs script-defined named streams 2. Named streams are prohibited by some config option 3. Let's pretend this stream is not actually what it is 4. Let's create whole new extension for that and put it into main PHP Exactly what I said in IRC earlier today. Both problem and solution look weird. I think this process is wrong. If we have problem with names streams usage in apps, we should seek solutions there, not invent modules just to work around the problem we ourselves create. What happens we need next application using named streams? Another extension into main PHP source whose purpose is to duplicate PHP code and work around our own security model? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ok just so there's no confusion.. Here's 2 examples why PEAR and pharPHP_Archive-based phar archives will no longer work once allow_url_include is off and user streams wrappers are marked as remote. So, it won't work with 100% of new installations in future PHP versions.