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

[Dale Henrichs]

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 ...

Dale