Re: Fwd: Re: dl() problem

SSB>> Convenience, modularity, ease of administration (or lack thereof for SSB>> people using shared hosting environments). With dl() you can SSB>> install an extension from PECL and use it immediately even in a SSB>> shared hosting environment. If I hosted by stuff in such an If you are managing shared hosting environment and allow users to install binary modules at their will - you obviously don't care for that environment too much. I wonder what hoster really does that and what uptime does he have after the users actually start doing it. Let alone what to do if two users start installing two different versions of the same module. SSB>> On top of that, many of PHP's extensions have additional options SSB>> where you can enable or disable features, and having the colo admin SSB>> change an extension could take even longer than having it installed SSB>> in the first place. You have lost me here. What extensions have options that are managed by using dl()? SSB>> Without dl(), using PECL will be limited to those in control of their SSB>> php.ini. Technically, there is really no reason for such a limitation. There is allright - those who aren't in control of php.ini aren't supposed to be in control for much more intimate details of the server - it's actual binary code. That's like not giving someone shell access but providing him a web tool allowing him to reinstall the kernel and replace any file on the system. Very weird security concept, I would say. SSB>> As Shane says, it is the current design of dl() that's broken. Let's SSB>> try coming up with a new design and reimplement it for 5.x instead of SSB>> making it Someone Elses Problem. That's what I was saying, but Pierre instead refers me to python, which, with all due respect, I don't intend to learn just for that. SSB>> One idea could be to "ghost" extensions in requests where they should SSB>> not be available. Instead of unloading the extension, its SSB>> functions/methods could be tagged as "disabled" (for example using a bit SSB>> in zend_function_entry.flags). The same trick could work for constants SSB>> and classes too. I fail to follow you about what goal you are trying to acheive. If you want to develop new dl(), let's start from the start - write a functional spec of what this new dl() should do. Then, after there would be some agreement about what it should do and if we really want to do it - we can get to how it could be done. SSB>> * Pro: persistent resources would work SSB>> * Con: extra check (although just one or two assembly SSB>> instructions) per function/method call and class/constant lookup One if per _each_ access to these tables. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.109