At 04:57 26.11.2002, George Schlossnagle wrote:

On Monday, November 25, 2002, at 10:43  PM, Ilia A. wrote:

On November 25, 2002 10:30 pm, George Schlossnagle wrote:
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.
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.
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.


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

--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to