[Seaside-dev] Can WAServerAdaptor be split up?

[Norbert Hartl]

I'm experimenting at the moment with setups to serve static files from a one click image without using file libraries. I'm trying to serve static files from within a one click distribution directory. Therefor I create a zinc server myself and I want to plug in seaside as a handler. Here is a snippet

start
   "file delegate serves from a neighbor directory 'web'" 
   staticFileDelegate := ZnStaticFileServerDelegate new directory: (
      FileDirectory default containingDirectory directoryNamed: 'web').

   server := (ZnServer on: self port)
      delegate: (
        "the next class just maps the first path element of a uri to a handler" 
	NTedContextDispatcherDelegate new
            map: 'css' to: staticFileDelegate;
            map: 'js' to: staticFileDelegate;
            defaultHandler: (ZnSeasideServerAdaptorDelegate with: ZnZincServerAdaptor new) ).
   server start

Whenever I start my server there is another adaptor created on port 8080. This is due to ZnZincServerAdaptor is an instance of WAServerAdaptor and always starts a server instance with a default being port 8080. 

In my opinion WAServerAdaptor has too many responsibilities. It does server management as well as request conversion. From a seaside point of view (being monolithic) this seems not to be a problem. But if seaside is _just_a_ handler it strikes back. 
I would like to divide the server management code from the request conversion. The request conversion/adaptor class could also be used in zinc directly. Meaning the only difference would be if seaside is the only zinc delegate or is a composited delegate. 
If it is important to keep a WAServerAdaptor as it is there could be one class having self as delegate resembling the current behavior. 

Any opinions? I would do the split up but I wanted to ask first if there is anything speaking against it.

Norbert