On Thu, 2004-02-12 at 11:00, Stanislav Malyshev wrote: > 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.
Valid point. So loading an extension twice should be handled more gracefully (not with one warning per function like now). > 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()? I was referring to compile-time options. > 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. If a hosting provider gives the web server user write access to the kernel, he deserved to be hacked out of business. But seriously, none of us are making these decisions for the hosting providers. Some give their users shell accounts, some run jailed httpds, some use fastcgi. IMHO our "job" is to create the best platform, providing the most flexibility. > 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. Alright. In the meantime, isn't it better to stick with the current dl() implementation without a deprecation warning until a replacement is available? My "ghost" suggestion was just an attempt at getting the ball rolling. We've had this issue for long enough now. - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
