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

[Philippe Marschall]

2008/3/24, Dale Henrichs <dale.henrichs at gemstone.com>:
> 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:

Maybe I wasn't clear enough, I was expression my initial opinion on
this, not a final verdict.

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

Thanks very much for this code. Now we have some real code to talk
about instead of simply mails. I will most certainly not delete them
unless we have something else that is working and accepted as "better"
by other parties. And even then I probably won't delete them. A
Seaside without SeasidePlatformSupport for anyone to look at.

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

That is true and we need to fix it, I added a bug for it:
http://code.google.com/p/seaside/issues/detail?id=38

> A broader problem
>  is that anywhere that startup lists _might_ be used could also rsult in
>  similar problems.

Right, but right now WAExternalID seems to be the only sender except
for the test. #addToShutDownList: seems to be there only for testing
purposes.

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

Ah, now I understand. Something like
SeasidePlatformSupport externalIdGenerator
Yes that would would work. I could certainly live with such a solution.

>  It's ugly, but I think we're pretty much caught between a rock and a
>  hard place....

Welcome to portable Smalltalk development ;-)

> I'm open to any other solutions.

"We" on the Squeak side are at the end of the food chain in the sense
that other platforms will have to work with what we produce so the
problems on our side are in general the smallest. I would like form
other platforms how they think about this issue. That's what this list
for, such discussions. If they don't respond I interpret that as they
do not care and will have to live with whatever we decide.

Cheers
Philippe