[Seaside-dev] on eliminating SeasidePlatformSupport

[Dale Henrichs]

Lukas Renggli wrote:

>> I'm still inclined to postulate that Seaside-Core will need a pre/post
>> platform-specific package (i.e., Seaside-PLATFORM-Base and
>> Seaside-PLATFORM-Core) to accomodate platform-specific superclasses and
>> subclasses. I'm also inclined to believe that SeasidePlatformSupport
>> will live on, because there are certain situations where a simple
>> platform-specific is the best solution. This weekend (or so) I'll do
>> another trial run for a pre-post scenario and attempt to eliminate
>> SeasidePlatformSupport by using superclass/subclass as seems apropriate
>> and see how that looks and feels...
>>    
>>
>
>I don't really see why. Currently there are no dependencies that would
>imply the need for a pre/post platform-specific package in Squeak. For
>PLATFORM=Squeak the -Base package would just be empty. Of course there
>is nothing wrong if porters decide to have a base-package that needs
>to be loaded first. VisualWorks for example loads the whole Squeak
>Collection and Date Hierarchy beforehand.
>  
>
Lukas,

You make a very good point here.

This morning in the shower, it occurred to me that I have been confusing 
the issue of pure portability with the fact that the GemStone version of 
Seaside is not just a pure port, but a port and a handful of extensions 
that add persistence support to the Seaside framework.

For pure portability, there is no need to add #doTransaction:, 
#randomClass, or #reducedConflictClass to SeasidePlatformSupport. For 
pure portability it is very straightforward to add startup/shutdown 
lists to GemStone. For pure portability, WAExternalID and WAFileLIbrary 
are just fine the way they are. For pure portability, 
SeasidePlatformSupport is just fine.

When it comes to adding 'transparent' persistence support to Seaside and 
extending the framework, then GemStone needs to replace Random with a 
TransientRandom (so that a new random number generator can be created at 
session startup without causing commit conflicts), for similar reasons 
we need to replace the use of the class Dictionary with 
RcKeyValueDictionary in a couple of spots. In the extended version of 
Seaside, startup/shutdown lists shouldn't be used, etc.

Over the last year or so, I have monkeypatched Seaside2.8 to make the 
mods needed to extend Seaside ... If you do a diff between  Seaside2.8g 
and Seaside2.8a1 you'll see a ton of differences, but the majority of 
them originate in the Seaside-Platform category. If you look at the 
changes that will be moved in Seaside2.9x and  ignoring 
development-related changes  (and extensions for a particular feature 
that modifies more of the core Seaside than I'd like), there are about a 
dozen methods monkeypatched in 4-5 classes (WARegistry, 
WAProcessMonitor, and WASession are the most interesting of the changes).

I didn't touch WAExternalId in 2.8g because the #startup method was 
never called, but when the tests to make sure that startup/shutdown 
showed up we were off to the races.

So instead of thinking in terms of pure portability, I assumed that 
Seaside2.9 would make it possible to extend Seaside without requiring 
any monkeypatching (except for the feature that modifies more of Seaside 
core than I like - this feature will continue to use monkeypatching in a 
separate version).

I was wrong to make that assumption.

In the longer run it makes sense to support a pure version of Seaside2.9 
that runs on GemStone that doesn't have the 'transparent' persistence 
support.  We will still be creating a 'transparent' persistence variant 
of Seaside and if we have to use monkeypatching to extend Seaside2.9, 
that's not the end of the world.

Dale