Am 28.02.2012 um 22:09 schrieb Yanni Chiu: > On 28/02/12 3:30 PM, Norbert Hartl wrote: >> >> I'm sorry that's all. I just started to do deployments with pharo >> lately. I was doing everything in gemstone until 2 month ago. > > That's interesting. Have you moved everything to Pharo, or is some part still > in GemStone? Can you outline why GemStone was not the better solution for > your use case? (I suspect that your dataset was naturally partitioned on user > boundaries).
Sorry for the confusion. The part about pharo and gemstone was not referring to this project. Most of my projects run in GemStone and I'm quite satisified with it. I started this project in pharo because the main assets are http messaging and multiple long running processes. Basically the zinc components are available in GemStone, too. But they are neither well integrated nor up to date. Could be better but that isn't a show stopper. It's more the long running processes. In GemStone I would need to start a separate vm in the system that cares about the running processes. Then you need to work out a communication scheme between your seaside UI model and the service vm. I would do this just to store a lot of request/response (dumb) data inside GemStone. I was thinking about it and felt that it just does not fit GemStone that well. Last but not least I liked the idea to be forced to play with some of these modern storage systems. To me GemStone and a combination of pharo with mongo db are not competitors. I find them pretty orthogonal in use cases possible. On the one hand there is GemStone where you can have a huge object graph with all the flexibility we like so much. I use this for more complex and highly interlinked models. Externalization of objects always restrict you in this respect. GemStone is a centralized database but one that can be distributed. On the other hand pharo is more flexible and has the more modern tools. The pharo use case here is to start a couple of tens, hundreds,... of images that either collaborate directly or via a distributed storage. And pharo can scale vertical in machine size being used. I would like to use pharo on tiny machines and let them participate in all of this. In between those two there is magma and on another far end there is amber. I think I want all of them so I always have the right tool whatever use case there might appear on the next day. If we are talking about scale than as a conclusion I can say that: I love smalltalk because it scales in "things possible" Uh, sorry for getting _slightly_ verbose and off-topic :) Norbert
