[Seaside] deployment question

[Norbert Hartl]

Am 04.04.2013 um 23:52 schrieb Dale Henrichs <dhenrich at vmware.com>:

> 
> 
> ----- Original Message -----
> | From: "Norbert Hartl" <norbert at hartl.name>
> | To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
> | Cc: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
> | Sent: Thursday, April 4, 2013 1:43:17 PM
> | Subject: Re: [Seaside] deployment question
> |
> | > So in the end I don't really think that you can say "DabbleDB got away with
> | > image based persistence" ...
> | > 
> | > Dale
> | > 
> | I think you can. IIRC each customer had his own image. Images are started on
> | request for a specific customer and shutdown after some time of inactivity.
> | So that is pretty much what I would call image-based persistency :)
> | 
> | Norbert
> 
> Norbert,
> 
> I wasn't necessarily questioning the image-based persistence part ... I was questioning the "got away with" part, implying that the DabbleDb persistence model was simple....
> 
> What happens if there are 10,000 customers and there are 10,000 images and you want to push out a bug fix? DabbleDb addressed this problem.
> 
> What happens if there are 1,000 customers who want to run at once and all of the images are located on one machine? DabbleDb addressed this problem.
> 
> What happens if...there are more ...
> 
> I am sure that you can think of creative ways to solve each of those issues, but my point is the with GLASS you don't have to invent custom solutions to the above problems...GLASS has built-in solutions to those problems ... GLASS also supports the image-based persistence model without requiring modifications to your code ...
> 
> I am not implying that GLASS is the right solution for everyone it has strengths and drawbacks just like everything else...
> 
> But to declare that GLASS is overkill and DabbleDb is the poster child for simple, image-based persistence? I think that's ignoring reality a bit:)
> 
> With all of that said, I go back to my original suggestion ... identify specific performance, scaling problems that you expect to encounter and then start searching for solutions ... the old adage about premature optimization applies ... 

Huh! I didn't want to say that you don't need gemstone. I mean I use it quite some time now exactly for that reasons and you know that. I just wanted to make a fun quote because DabbleDB literally did image….based…persistence. That's all!

Norbert