Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37611
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <48289F7E.9010305@zend.com>
Date: Mon, 12 May 2008 12:50:22 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Hector Santos <hsantos@isdg.net>
CC: internals@lists.php.net
References: <4824219D.3070806@isdg.net> <4824EEAA.3080901@isdg.net> <48287EFC.4090205@zend.com> <48289A67.7040100@isdg.net>
In-Reply-To: <48289A67.7040100@isdg.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Extension_Dir: Proposal to offer multi-directory DLL
 loading
From: stas@zend.com (Stanislav Malyshev)

Hi!

> In PHP52, it allows only relative paths:

Right, but 5.2 is stable version so I don't see new features going 
there. Thus I think it's better to discuss 5.3 for new stuff, unless 
it's something so critical that it must be in 5.2.

> 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.

I don't need multiple copies. But I may want to keep it in the same 
directory the extension is - otherwise I'd have to add the directory to 
windows path, which add overhead to install. By keeping all the stuff in 
the same directory, it'd work out of the box.

> Today, if an application server wish to implement PHP, it will need to 
> add its PHP extensions into the single extension_dir location.

Either that or use full paths in php.ini, depending on how the server is 
structured.

> 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.

Why? Just put all the stuff into that extension directory, if you talk 
about Windows. On Unix, .so resolution rules won't help here, but having 
extension path is not going to change anything.

> The include_path resolves the script issues, but we don't have the same 
> flexibility with DLLs.

I'm not sure what do you mean here. If you mean that PHP extensions use 
external DLLs, then you have two cases:
1. DLL is used only by PHP extension, nothing else uses it. Resolution: 
put it in the same directory PHP extensions are.
2. DLL is used by other stuff (external programs, etc.), not only PHP. 
Resolution: put it into separate library directory and add the directory 
in system PATH.

In both cases, I don't see how path for _extensions_ is helping you, 
unless all your application lives in the same directory and for some 
reason it's not possible to either add it to the path or use full pathes 
in php.ini extension= directives (but is possible in extension_dir 
directive).

>     a) copy our DLLS into PHP "extension_dir" folders,
>     b) copy them to a windows PATHed folder,

If it's external use DLLs, b) is the right way to go. It is regardless 
of the extension - if multiple parts of the application use same DLL, 
and they may reside in different directories, PATH is only way I can 
think of that makes it work.

> - PER application multi-ini include support. Scattered material seem
>   to suggest this is possible, I have not seen how.

You can do it in 5.3 with "user ini files", but it's not documented yet, 
unfortunately. Hopefully, it will be soon.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com