Steph Fox wrote:
Hi Pierre,
OK, I got back to the rest of your email now (caffeine always helps, eh).
I'm not sure it makes sense to have the ssl optional features enabled
but not ext/openssl. Or to say it better, I don't see the gain. What
is the gain besides being able to say: "heh you can use the ssl
features without having ext/openssl but you need the libs anyway"?
You're missing that Windows users don't tend to roll their own PHP.
They tend to pick and choose their extensions.
At present, if someone were to load php_openssl.dll from PECL
alongside built-in Phar in 5.3 they'd probably wonder why it wasn't
working as advertised. If the dependency were made explicit in Phar,
the only thing ext/openssl would be needed for is explicit openssl
calls - which is far easier to understand.
FWIW, I think having Phar built-in is actually a disadvantage when it
comes to this kind of thing. ext/openssl isn't enabled by default and
is only available as shared to the vast majority of Windows users.
Hi,
I must be going crazy. Is there an actual problem that needs solving?
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? Why?
ext/phar uses openssl, and thus works in all of these situations:
1) ext/phar built statically and ext/openssl built statically (in this
case, it uses openssl lib directly)
2) ext/phar built statically and ext/openssl built dynamically (in this
case, it checks for openssl dynamically at runtime, and directly calls
openssl_sign or openssl_verify)
3) ext/phar built dynamically and ext/openssl built dynamically (in this
case, it checks for openssl dynamically at runtime, and directly calls
openssl_sign or openssl_verify)
4) ext/phar built dynamically and ext/openssl built statically (in this
case, it checks for openssl dynamically at runtime, and directly calls
openssl_sign or openssl_verify)
#1 is the fastest alternative, but the difference is insignificant for
any application of significant size, as the extra code in #2, 3, and 4
is only called once.
On windows, the user would have (by default) phar static and openssl
dynamic. 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. Once done, phar then works great with
openssl signatures.
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.
Pierre: the difference between phar and other extensions is that phar
has the ability to handle all 4 of the above situations for bz2, zlib
and openssl, whereas no other extensions possess this kind of true
optional dependency handling. So, I fail to see how the use of runtime
extension detection is anything other than a really great idea that
solves the problem of optional dependency handling regardless of
static/dynamic compilation.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
