Re: [PATCH] Redirect on Error
| From: | (Marcus Börger) | Date: | Tue, 26 Nov 2002 04:23:33 +0000 |
| Subject: | Re: [PATCH] Redirect on Error | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-91640@lists.php.net to get a copy of this message | ||
At 04:57 26.11.2002, George Schlossnagle wrote:
On Monday, November 25, 2002, at 10:43 PM, Ilia A. wrote:WE can use cdb (constant databse) which is very fast and we have the code bundled now. The documnet group might want work on error messages XML based. We may write a script wich will generate a cdb file from that XML file. However i would VERY MUCH appreciate having english error messages hard coded into the source. AND those i18n error messages only activateable by an ini setting.On November 25, 2002 10:30 pm, George Schlossnagle wrote:dbm lookups are fast, as are (to a lesser extent) file system lookups. Neither consume any process memory. Neither require an entire database to be loaded, simply to have the entry looked up in them.There is no proposed patch to affect all these changes. There are fine ways to print errors that don't necessitate having them loaded at run time. They could be in a dbm file, or even a flat file hierarchy and loaded on demand. This would not be as fast as a hash table, but when you're actually printing errors, a slight overhead seems acceptable (to me, ymmv)If we were talking about a one time script that is execute and forget then you are absolutely right. But what about if a web server enviroment where a child/thread can remain in memory indefinitely. Or a web hosting enviroment where the admin has no control over the script of the users, loading & (unloading?) of the error messages database will add overall overhead non the less.
And if you're running an hosting service for users, performance is sort of out the window anyway.This is also not as easy as it sounds, for example a gettext a commonly used tool for localizations, is not thread safe, so we are looking at having to design a error localization mechanism with a thread safe disk database system.Well, fortunately, this being an open-source project this burden need not lie with you if you don't want it to. I'm somewhere between +0 and +1 on this issue. I think it would be helpful, a nice feature to have. and generally increase accessibility. I don't think that an implementation would necessarily incur overhead unless error functions are being called. George -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php