<snip/> > Is this buffer size only related to development ? I don't think so.
Well, of course not necessarily... but at least I wouldn't want this burden that will definitly mean a drop of performance and worse scaleability for our deployed system. The question is: for what type of user do we create those nice error messages? Actually from our clients I can tell - they don't have the slightest idea what a specific exception could mean. And I bet same goes for most of the web users out there. If there is an error they will call anyway and I have to look into the logs. (Of course a nice page "Sorry, unavailable" is much nicer - but we need to see what is the price to pay. But where it can definitly help to speed things up is at the development stage... No more: "wait I need to turn this category on - do it again" or "wait I need only 10.000 more lines to go through" But of course people may see this differently... ;) > Error-handlers can also be used in production to handle > exceptional-but-foreseen conditions (access denied, unavailable > resource, etc). So the buffer size isn't only a matter of running mode. Well, of course... but I would model such conditions within the sitemap and don't use Exceptions ;) ...if they are foreseen... > However, running mode is a great idea, which could be used for many more > things than buffer size : > - central configuration for automatic reload of XSPs and sitemap in dev > mode (and no reload in production mode), > - display the Cocoon "blue screen of death" to the browser in dev mode > and a gentle "system currently unavailable" in production mode, > - other ideas ? Hey, I didn't thought about all that... sounds cool:) - provide different logkit configurations? -- Torsten ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
