[Seaside-dev] question on value of startup and shutdown lists being required

[Philippe Marschall]

2008/3/23, Dale Henrichs <dale.henrichs at gemstone.com>:
> In Seaside2.9 system startup and shutdown lists are "required." I am
>  wondering how necessary these lists are. It is easy enough to implement
>  the startup and shutdown list, but I question their overall value. Doing
>  things at startup is problematic because most of the useful things that
>  are done at startup in other Smalltalks usually involve reseting a class
>  variable or other global (as in the WAExternalId) which _will_ lead to
>  commit conflicts in GemStone.
>
>  Fortunately, only WAExternalId uses the system startup list. The
>  shutdown list appears to be unused.
>
>  In GemStone we have a technique for refreshing things when a new session
>  is started without creating commit conflicts and without sending
>  messages at vm startup.
>
>  I would think that using startup/shutdown lists is more of a
>  platform-related technique used to solve specific problems as opposed to
>  being an important part of the overall framework.
>
>  In the specific case of WAExternalId, we need a fresh Random number
>  generator for each vm, but there are several ways to accomplish that ...
>
>    1. get the generator instance from SeasidePlatformSupport - causes
>       bloat, but is offset by eliminating platform startup/shutdown.
>    2.
>
>       have WaExternalId use a variety of Random (implemented as a
>       Platform specific class) that refreshes its seed on system
>       startup. In the non-GemStone case, the implementation would
>       forwarding messages to a global where an instance of Random is
>       stored. The instance is refreshed on startup....
>
>    3.
>
>       leave the startup method alone, but make it's use a platform
>       dependent, i.e., on non-GemStone platforms WAExternalId would
>       register for startup messages directly in a platform-specific
>       message (#registerForStartup). #registerForStartup would be a noop
>       in GemStone.
>
>  I assume that there are other possibilities.
>
>  At the moment I lean towards option 3.
>
>  Let me know what you think and I'll code it up ...

One thing to keep in mind is package loading and package
initialzation. Right now is looks like this:
- provide Continuation
- provide SeasidePlatformSupport
- "normally" load Seaside-Core where "normally" means at the end
happends class initialization

The way I interpret 3 between loading the code and #initalize-ing the
classes some other code has to be loaded in this case WAExternalId
class >> #registerForStartup.

Cheers
Philippe