Oleg,

As others have mentioned you need to have the 64bit hardware to run 
GemStone. There would be a significant amount of work for us to port our 
64bit product to run on 32 bit architectures, so we won't be heading in 
that directions.

We have recently announced a non-commercial version of GemStone 6.2 is 
available for the Mac (Tiger on x86). GemStone 6.x is the 32 bit line of 
our server. This is an option that could be followed.

On the other hand, if you are developing an application (with plans to 
deploy on GemStone), then it is actually a very good strategy to develop 
in Squeak and deploy in GemStone. Our first GLASS customer to go into 
production did just that. They started developing their application in 
Squeak long before we even a beta ready for GemStone (in fact they did 
their development using Seaside2.7), then when we had our beta ready 
they ported their application from Squeak to GemStone (using Seaside2.8).

As Boris has mentioned, taking advantage of GemStone persistence is as 
simple as storing things in class variables. Anything that is kept alive 
in your Squeak image will be kept alive (and persisted) in GemStone. In 
a Seaside application, the framework does the commits, so there is 
literally no need to change you application when you move it to 
GemStone. A good set of unit tests is recommended, but then thats a good 
idea no matter what your deployment plans are.

You _do_ have to be more aware of concurrency issues in a GemStone 
application than you do in an image-based application. Intra-session 
data structure access is protected by object locking in the framework, 
but for data structures that may be updated by multiple sessions (places 
where you would be using Semaphores to protect data access in a Squeak 
Seaside application) you will likely need to use some GemStone-specific 
reduced conflict classes.  I have plans to write a blog post to cover 
the options in more detail - after today's discussion, I will probably 
write it sooner rather than later.

In general, you will be doing very little GemStone/persistence-specific 
code in a Seaside application that is targeted to be deployed in GemStone.

In the end, I think it is very possible (and even desirable) to develop 
your Seaside app in Squeak with plans to deploy in GemStone. I would 
think that you can get away with doing quite a bit of development, 
before really needing to get access to GemStone and 64 bit hardware.

Dale