[Seaside-dev] WAMutualExclusionFilter

[Julian Fitzell]

I was imagining you would want to have a different filter there, yes.
It's currently being added by the Session itself because we really
don't have a way of configuring sessions (this is Issue 263). This
will make it harder for you to have your own filter of course...

As for Environment, I have to admit I was imagining other platforms
just creating their own Environment packages if they didn't like ours.
WAEnvironment is really just a class to hold some initialization
methods that can be run after all the other packages are loaded. The
WAHtml* classes could arguably be pulled out somewhere else but again
it was a trade-off against having too many tiny packages. We could
re-evaluate this id desired.

I agree we need better mechanisms for configuring things. I was
imagining commands in the Tools package that would perform actions to
facilitate setting up for deployment and so on. I sort of picture them
being command classes, somewhat like OmniBrowser has. But I'm hesitant
to do more than the simplest thing that could possibly work now for
this release. It will take some design and experimentation to figure
out something that works better.

I think the simplest thing in this case would be for you to fork the
Session package and change #initializeFilters? You could also subclass
Session, I suppose, but that seems less ideal.

On the other hand, you know what you need better than we do, so if
there's another simple solution that's fine too.

Julian

On Fri, Nov 20, 2009 at 4:04 PM, Dale Henrichs
<dale.henrichs at gemstone.com> wrote:
> For GemStone, I am going to have replace the implementation of WAMutualExclusionFilter with one that plays better in the GemStone environment. WAMutex end up being saved in the image with the session state, and there is a 'naked reference' to the owner process which when a debugger is opened in a development image, can result in invalid attempts to commit the semaphore that is (usually) ob the stack when you get a walkback ...
>
> With multiple vms a semaphore doesn't cut it anyway .... if fact I can imagine a couple of different MutualExclusion filters that I may want to introduce.
>
> So I am wondering what the approved techniques are for slipping that in would be ... it feels an awful lot like choosing the error handler ...
>
> Which leads me to be thinking along the lines of how _a_ default error handler is defined by WAEnvironment ... which leads me along the lines of making it possible to have platform-specific control over WAEnvironment...
>
> WAEnvironment current? It has the advantage of giving folks a place to hook in their own production/test/development environments and providing a guideline for what needs to be specified.
>
> Having production/test/development environments would help to clean up the Seaside-Development dilemma, since one of the 'error handling' options for the environment could be flow-free ...
>
> Let me know what you think...
>
> Dale
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>