orichards at mail.ru
Sat Dec 15 07:00:29 UTC 2007
Dale Henrichs wrote:
> 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.
> seaside mailing list
> seaside at lists.squeakfoundation.org
Dale! Thank you for the time for explain. Currently i am developing using
visual works in parallels. First version of my application has been already
in production windows server 64bit for 2 months. In vw again. I like squeak
development, especially Ramons image. But i cant use it. I need to type
unicode characters using keyboard, or even be sure that i can load them. My
financial reporting system works in huge corporation and i have many
requests from others to show it. I need persistence. Now i have my homegrown
system, but i think that if there is something better i can recommend
customers to buy it. There is another problem - i did not heard about
gemstone specialists here. So what will you recommend?
View this message in context: http://www.nabble.com/Monticello-in-GemStone-tp14324385p14348562.html
Sent from the Squeak - Seaside mailing list archive at Nabble.com.
More information about the seaside