Hi Greg,
I must be going crazy. Is there an actual problem that needs solving?
Yep, solved yesterday.
You're saying that a user who improperly installs php_openssl.dll (i.e. does not follow instructions and set up ssleay.dll and libeay.dll) should magically be able to use phar with openssl?
No?
On windows, the user would have (by default) phar static and openssl dynamic.
Only if they run PHP 5.3. Remember I'm still, piece by piece, putting together a version for PECL/5.2 - and also remember that it's 50-50 whether phar goes out as static or as shared even in 5.3.
To enable openssl signing, you simply need to enable php_openssl.dll, which means setting up a few dlls as described on the installation page for openssl.
Not so simple. You have to put a weird file in a weird place for ext/openssl to operate at all. The docs on that are appalling (everywhere), it took me 15 minutes to work out what was wrong with it... If you use phar-ssl you don't have any of that kind of thing to worry about. If you have ext/openssl installed you don't need to use phar-ssl.
Where is the problem? Any user who has control over their windows build and wishes to compile in openssl statically for maximum performance may do so, but I would challenge any user trying to eke out such a small performance gain would be better served by using unix, where PHP is just plain faster no matter what.
I still think Option 2 is wide open - i.e. get rid of the native openssl calls in ext/phar and have openssl support only when ext/openssl is available. If the performance gain isn't an issue then the only advantage of having that code in phar is to avoid a mildly problematic ext/openssl setup.
- Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
