Erik Enge <erik@nittin.net> writes:
Marco Baringer <mb@bese.it> writes:
1) what's a good default action for:
a) we get a request with a "bad" session id
b) we get a request with an in-existent action-id
c) we get a request with an in-existent frame-id
I'm unsure what you mean by the word "in-existent" not I'm going to assume you mean nonexistent. I would say signal a condition in all three cases and register default handlers for them in ucw in case the user does not. The default handlers could probably just return an error message of some sorts.
[ "in-existant" is a (i think plausable) non word i made up from the various languages floating around in my head. :) ] The quesetion is about garbled urls. If i were to send a request for the action A in the frame F and the session S what do we do if A or F or S is an id string which daesn't have a corresponding action, frame or session. At the moment (in the 0.1 dev tree) we log the error and send a simple message back to the requesting browser. Since this really can't happen unless ucw's core is borken i think this solution is sufficent.
You mean the user as in the user who uses the webbrowser as opposed to the developer using ucw? Well, I'd say use the conditions and then it's up to the developer.
user as the "the browser which made the request." Sometimes this is a developer whose building the app, and in this case we probably want one kind of response, sometimes this is an end-user whose using a (supposedly) stable app and we don't want to confuse them.
2) since there are quite a few things which we want to handle differently in a dev enviroment than in a production enviroment do we want a global ucw:*debug-server* variable or a sub class of application?
I guess my knowledge of ucw is not up-to-speed yet as I'm not really sure what you are refering to. I'd say ucw should signal the same conditions irregardless and then let the developer decide what to do in which situations.
My question is: how does the developer specify what do? We're talking about the situation in which a completly unexpected error has caused the request processing to barf, in this case we've signalled an error server side and can't continue without some kind of "hand-of-god" intervention. Since most of the request handling protocol is done via methods specialized on the class application we could simply provide various application sub classes, one would return "internal surver error, please try later" (and create a dummy page somewhere with an inspectable backtrace so that developers could go see what happened (oh, that's a good idea...)), one would return an inspectable back trace, and one would simply drop the server into a debugger and leave the browser waiting. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen