[Seaside-dev] questions about WAServerAdaptor

Julian Fitzell jfitzell at gmail.com
Mon Nov 10 12:45:14 UTC 2008


On Sun, Nov 9, 2008 at 11:09 PM, Philippe Marschall
<philippe.marschall at gmail.com> wrote:
> My idea is that WAServerAdaptor has an instance variable status that
> holds an instance of a subclass of WAServerStatus. The code would then
> look something like this
>
> WAServerAdaptor >> stop
>    status := WAStoppingStatus new.
>    self basicStop.
>    status := WAStoppedStatus new
>
> with WAStoppingStatus and WAStoppedStatus something like the code
> outlined in the previous mail. .

Right, so then the problem with that seems (to me) to be that it does
not necessarily reflect the actual status of the server that the
adaptor is abstracting. #basicStop

I do kind of like the idea of having State (is State better than
Status?) objects though. It means, for example, that you could have
more specific subclasses for some adaptors. WAStoppingState and
WAStartingState could both be subclasses of WANotListeningState, for
example, and so not all adaptors would have to use them. Presumably
you would just implement #state, which would allow you to combine
logic better. And in fact, that allows the basic states to be
Listening and NotListening, which is probably clearer.

It might be worth having an "active" instvar on WAServerAdaptor, and
setting it to true or false automatically when the adaptor is started
and stopped, much like you are doing there. This could serve as the
queue when starting an image to know which adaptors to restart. This
is probably cleaner than having another collection on WAServerManager.

But I think there is a distinction between "starting" the server
adaptor (and checking whether it is "started") and checking the actual
status of the server (as I said above, perhaps "listening" would be
clearer).

Feel free to experiment... this is definitely work in progress. Just
try to keep the Control Panel up to date as well.

Julian


More information about the seaside-dev mailing list