[ucw-devel] random questions

[Marco Baringer]

Erik Enge <erik at nittin.net> writes:

> Marco Baringer <mb at 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