Stanislav Malyshev wrote:
Hi!
Let me simply ask, do you think there is technical merit (worth while)
to create a patch which offers multi-directory DLL loading support for
the PHP.INI extension_dir= option?
extension is an one-time configuration directive. Since it allows full
path now, how hard would it be to get it right with full path?
In PHP52, it allows only relative paths:
extension_dir="./ext"
extension=../special/php_specialext.dll
Attempting to clear extension_dir does not work in an attempt to use a
FQFN (fully qualified file name).
Example, for FQFN extension
extension=c:/php/special/php_specialext.dll
None of the following will works:
extension_dir=""
extension_dir=
;extension_dir=
PHP53 was updated to override the extension_dir= location IFF there is a
directory separator in the extension= file name.
Multiple paths may contain some dangerous pitfalls - like, what happen
if extension is in multiple paths, and in some it's not compatible
(wrong version/debug/ts)? What if you have some old version lying around
in fifth path, and you had new version in first path, but somehow
permissions got mangled and it's not readable, so wrong version is
loaded? Etc., etc. - it seems to have potential for many unpleasant
moments.
Possible. But this is partly the reason why I think it applies, as I
will note below.
1) Reduce extension DLL (non-PHP related) dependency issues,
How? I'd say, if you have extension A using foo.dll, and extension B
using foo.dll, and they live in different directories, don't you now
have to maintain two copies of foo.dll instead of one?
But if you are single sourcing foo.dll, why would you want to have
multiple copies floating around? Thats partially the point there, more
importantly non-php related foo.dll is in one location outside of PHP.
Consider foo.dll to be a "system.dll" where only 1 version is expected,
"DLL From Hell" issues.
2) Better support for PHP integration with Application Servers, and
Here I'd like to hear more - how it helps PHP and Application Servers?
I'm a bit surprise you have to ask. :-)
3) Better support for security isolation, sand-boxing applications
I'm not sure how giving multiple places to put security-sensitive stuff
(extension has access to everything) improves sandboxing, could you
explain?
Today, if an application server wish to implement PHP, it will need to
add its PHP extensions into the single extension_dir location.
For an application server that traditionally does not desire for its
DLLs to be floating outside its controlled environment, PHP does not
play well here.
Our package is a long time integrated RPC client/server framework and,
we keep everything under one secured folder. No need for PATHS. No need
to copy dlls. The primary reason is to control versions issues and
customer auto updates into one known location - isolation.
With increase customer usage of PHP and 3rd party developer demand for
direct PHP support, for which we currently only provide generic
CGI/script mapping support, we began to write an extension
to expose the 150+ server API to the PHP language and added PHP to our
SDK suite of language support; C/C++, Java, VB, VFP, Delphi, .NET and
now PHP.
Immediately we found isolation issues in regard
- PHP library/classes,
- DLL dependencies issues.
The include_path resolves the script issues, but we don't have the same
flexibility with DLLs.
Our server is a RPC client/server system and each RPC client
requires our DLL interface files, including the new PHP extension we
wrote (a total of 3 of them) which are basically wrappers to our RPC
client dll API interface.
The unreleased package includes many PHP examples to illustrate how PHP
can work with our system and we found we have to either:
a) copy our DLLS into PHP "extension_dir" folders,
b) copy them to a windows PATHed folder,
c) add a DELAY_LOADING concept to the PHP extensions which
allow the extension's dll_main() process_attach logic
to prepare finding its server dependencies.
The latter is how we currently have it working now, but not something we
really wanted to do because of the method it uses.
Since the above extension= full path idea does not work, we would left
(pressured) to look at the possibility of altering PHP itself. Hence
why I am here.
We also expect to add direct embedded/sapi support and this will 100%
require PHP to work around our centralized server focus, not an embedded
language as the central focus.
I think the same will hold true in the application server growth market
where PHP needs to fit into better, and not the other way around.
Thus far, I can provide a quick summary review of two items where I
think PHP can be improved:
- multi-path extension_dir support
- PER application multi-ini include support. Scattered material seem
to suggest this is possible, I have not seen how.
Think of an application server being "PHP Ready" with a PHP
configuration file that is already available, always distributed.
If a customer wants to install PHP, all it needs to do is add a line
such as:
appserver_ini="c:\wcat\wcphp.ini"
or have a new INI folder concept:
appserver_ini_dir="./ini"
where applications that place their specific INI and PHP will reads
these INI files.
The ini will have the overriding PHP requirements, for example, this is
the WCPHP.INI we add to the PHP.INI during installation for an existing
PHP installation. You can imagine the complexity in augmenting an
integration with possibly existing other system setups, i.e, adding to
the include_path= rather then replacing it, etc.
;----------------------------------------------------------
; wcPHP PHP.INI configuration file.
; minimum setup. see complete php-recommended.ini for
; more options
;----------------------------------------------------------
[PHP]
doc_root =
cgi.force_redirect = 0
cgi.fix_pathinfo=1
include_path =".;c:\wcat\php\code"
extension_dir =".\ext;c:\wcat"
extension=php_pdo.dll
extension=php_pdo_sqlite.dll
;----------------------------------------------------------
; PHP Wildcat! Extension
;----------------------------------------------------------
[wildcat]
allow_call_time_pass_reference = On
extension=php_wildcat.dll
extension=php_wscgate.dll
extension=php_wcdoor32.dll
; Wildcat.Server defined the server computer name to connect to
; Leave it blank to connect to the current server.
; Wildcat.AutoConnect flag allows to auto connnection and
; reestablishing the current user connect.
wildcat.server = ""
wildcat.autoconnect = 0
;----------------------------------------------------------
; wcShareNet Configuration
;----------------------------------------------------------
[wcsharenet]
wcsharenet.pdo.drv = "sqlite"
wcsharenet.pdo.dbf ="c:/wcat/wcShareNet/wcShareNet.db"
wcsharenet.pdo.dsn = ""
wcsharenet.pdo.uid = ""
wcsharenet.pdo.pwd = ""
--
Hector Santos, CTO
Santronics Software, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
