From mb at bese.it  Mon Dec  8 19:02:25 2003
From: mb at bese.it (Marco Baringer)
Date: Mon, 08 Dec 2003 20:02:25 +0100
Subject: [ucw-devel] random questions
Message-ID: <m24qwbrv3y.fsf@bese.it>


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

  While we could just respond with some kind of error message i'd like
  to offer the user some pollible ways to react, but what? does this
  depend on whether it's a dev server or the production server?

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'm leaning towards the latter as it would be a good
   test of how well the application api is defined)

3) mind if i kill ucw-devel at common-lisp.net and just do everything on
   bese-devel at common-lisp.net?

-- 
-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




From erik at nittin.net  Tue Dec  9 01:32:02 2003
From: erik at nittin.net (Erik Enge)
Date: Mon, 08 Dec 2003 20:32:02 -0500
Subject: [ucw-devel] random questions
References: <mailman.537.1070909950.20290.ucw-devel@common-lisp.net>
Message-ID: <87wu96rd2l.fsf@nittin.net>

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.

> While we could just respond with some kind of error message i'd like
> to offer the user some pollible ways to react, but what? does this
> depend on whether it's a dev server or the production server?

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.

> 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.

> 3) mind if i kill ucw-devel at common-lisp.net and just do everything on
> bese-devel at common-lisp.net?

I don't mind.

Erik.


From mb at bese.it  Tue Dec  9 09:15:24 2003
From: mb at bese.it (Marco Baringer)
Date: Tue, 09 Dec 2003 10:15:24 +0100
Subject: [ucw-devel] random questions
References: <mailman.537.1070909950.20290.ucw-devel@common-lisp.net>
	<87wu96rd2l.fsf@nittin.net>
Message-ID: <m2zne2s66r.fsf@bese.it>

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