Can WAServerAdaptor be split up?

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_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Hi Norbert,

Sounds like a reasonable argument... so you'd have a RequestAdaptor and a ServerAdaptor or something?

Two thoughts:
1) It might make sense to do this on the 3.1 branch as it's sort of an architectural change, though I guess it can be done backwards-compatibly, so maybe not necessary. (actually, we'll need to look at pulling new changes from 3.0 over to 3.1—there's not much in there yet, but it would be nice to get the continuation-as-request-handler stuff soonish)
2) I've been experimenting in that branch (but haven't committed yet) with making ServerAdaptor a subclass of RequestHandler. This works really nicely because it can sit in the handler stack and represent the root of the path: it can provide the default codec, the base URL of the server, allows wrapping with decorations, and so on. One question I've had is whether there should be a composition rather than subclass relationship here; maybe the RequestAdaptor is the thing that should be a RequestHandler and the ServerAdaptor should be responsible for setting the codec and URL properly on the RequestAdaptor.

Don't worry about making the RequestHandler change unless you're interested (in fact, probably better to do the refactoring in a separate step anyway), but worth keeping that in mind as you're doing the split.

Julian



_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Hi,

In the regular Seaside mailing list, I wrote a message 'Running ZnZincServerAdaptor outside WAServerManager', describing my first attempt at solving Norbert's problem, within the existing architecture.

Sven

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Sun, Jan 6, 2013 at 12:48 PM, Norbert Hartl <[hidden email]> wrote:
Form memory without checking the code:
WAServerManager does the server management. AFAIK WAServerAdaptor
automatically registers. You should be able to either stop or
unregister the server adapter and then no starting or port binding
should happen.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev