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

[Dale Henrichs]

Philippe Marschall wrote:

>2008/3/23, Dale Henrichs <dale.henrichs at gemstone.com>:
>  
>
>>Philippe Marschall wrote:
>> > 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
>> >
>>
>>In my earlier attempt at 3, #startup and #registerForStartup need to be
>> platform specific methods. I can make startup platform independent (with
>> a platform-specific extension method to Random), but I'm stuck with
>> #registerForStartup as a problem - it would be nice if there were a post
>> Seaside-Core platform-specific package.
>>
>> Perhaps we can create a Seaside-Squeak-Extensions (and
>> Seaside-GemStone-Extensions) package for the handful of extensions that
>> are currently needed (including the squeak-specific 'cyclic dependency'
>> extensions).
>>
>> This approach would certainly solve the registerForStartup problem right
>> now. I assume that as I move forward with my port, I will find other
>> places where a post core load will be useful. There already is a
>> platform-specific package for development extensions, so I assume the
>> we'll end up with platform-specific core extensions in more areas.
>>
>> You know, if we use a platform-specific extensions package, we can
>> eliminate SeasidePlatformSupport - I don't know if that would be a good
>> or bad thing. It is convenient to manage things in one spot, but given
>> a  thorough test suite (which is already in place for most if not all of
>> the base class extensions) it isn't necessary....95% of the references
>> to SeasidePlatformSupprt messages are from a single method or a single
>> class.
>>
>> If we do eliminate SeasidePlatformSupport, then the platform Core
>> package (except for Continuations) can be loaded after Seaside Core.
>>
>> What do you think?
>>    
>>
>
>It makes loading classes harder and knowing what to implement harder.
>
>Right now you can use normal class initialization in Seaside-Core
>(class >> #initialize) and you can expect SeasidePlatformSupport to be
>present. With your change initialization of classes in Seaside-Core
>would have to happen in Seaside-Platform-Extensions.
>
>If you want to know what methods you have to implement you can look at
>WASqueakPlatform and you should have most of them.
>
>As for the file stuff a lot of this can be implemented with SPort and
>has already been done so in Seaside-Sport-Core.
>
I won't argue with that....go ahead and delete these versions:

   * Seaside-Core-dkh.82
   * Seaside-Squeak-Continuation-dkh.1
   * Seaside-Squeak-Core-dkh.34
   * Seaside-Tests-dkh.70

Back to my original problem, which at its bare minimum is that: using 
the system startup list to reinitialize the Generator class variable in 
WAExternalID  will cause commit conflicts in GemStone. A broader problem 
is that anywhere that startup lists _might_ be used could also rsult in 
similar problems.

The simplest solution is to keep the Generator in SeasidePlatformSupport 
(class var or global reference) itself and a have platform-specific 
mechanisms for guaranteeing that the Generator instance is refreshed 
(startup lists in Squeak, etc. and Transient classes in GemStone).

It's ugly, but I think we're pretty much caught between a rock and a 
hard place....I'm open to any other solutions.

Dale