[Seaside] Using Dynamic Bindings in Seaside rendering

[Stephen Pair]

Cees de Groot wrote:

>On Mon, 2003-05-12 at 05:33, Stephen Pair wrote:
>  
>
>>Besides, if you take this approach in Squeak, the debugger won't work at 
>>all with it (since the debugger uses a different process for debugging).
>>
>>    
>>
>I noticed that :-). OmniBase uses the same method (a bit different
>variation, a class-side dictionary keyed on process) to keep a tab on
>the 'current' transaction, so under Squeak, you cannot debug processes
>that access the current transaction.
>

In fact, DynamicBindings evolved out of RuntimeEnviornments (same 
implementation pretty much as ProcessEnvironments and what you describe 
for OmniBase), which was created mainly to keep a transaction context 
for Kats.  I had the same problem with the debugger not being able to 
debug processes that access the current transaction...at the time, I 
felt that the debugger should be improved to handle that...now, while I 
still feel like the debugger could be improved, I also feel like a stack 
is a stack and it should matter what process is runnig it.

>Normally, certainly for web processing, I'd say forget about these
>special cases and keep the simple thing - you're theoretically right,
>but all the web/app servers I know assign a request to a thread/process
>and keep that assignment for the duration of the request. However, with
>Seaside being such an eminently good example of the usefulness of being
>able to separate stack and process, I'm not so sure anymore ;-).
>

Well, Seaside is what conviced me (well, actually it was Avi brow 
beating me about the inappropriateness of keeping things in Process (or 
keyed by Process)).  And, just because everyone else does it that way 
doesn't mean that it's right.

>>And a ProcessEnvironment has this who knows what stack the process might 
>>be running trickiness.
>>    
>>
>You'll have to admit here that that's almost always a simple 1:1 mapping
>that doesn't chance.
>
>  
>
>>  Saying that dynamic bindings are tricky is like 
>>saying that exception handling is tricky (an exception handler is a 
>>dynamic binding after all)...
>>    
>>
>Exception handlers *are* tricky. That's why a lot of people don't like
>them, and use them only for exceptional circumstances, grudgingly...
>

Well, code that doesn't make effective use of exception handlers tends 
to be even more tricky.  Have a look at VisualAge sometime...they insist 
on returning error codes in a lot of their classes, and it's a total 
pain to deal with.  Exception handling may be a bit tricky a first, but 
so are a lot of useful things in software development.


>>they are tricky, until you understand them 
>>and know when it is appropriate to use them, and when it is not.  I'd 
>>recommend that you have another look at dynamic bindings.
>>
>Oh, I understand them enough to decide on their appropriateness and
>judge the dangers. That's why I want to make sure that it really is the
>best option in this case which involves checking off some 'known good'
>alternatives. I'm happy with the solution as long as it is the best one.
>
>(somewhere back in my head this Squeak-E project is still using spare
>braincycles. Currently, a dim red question mark is flashing right behind
>the question "yes, but by dynamic bindings you can influence
>computations that go on lower in the stack - isn't that a security
>risk?")
>

It's no more a security risk than global variables, ProcessEnvironment 
variables, or Unix environment variables...all of which affect 
computations that go lower on the stack.  In fact, if you're really 
careful with the implementation, ProcessEnvironment is identical to 
DynamicBindings.  ProcessEnvironments and DynamicBindings both do 
essentially the same thing, just different implementations.

- Stephen