[Seaside] Summer of Code Project

[Boris Popov]

Interesting thought, indeed, but I'm struggling coming up with a good
way of identifying customers to pass control to respective images,
unless we direct them to use different URLs ala DabbleDB or have a
separate app fronting the login page to determine credentials that way,
neither of which would work very well here. Any other ways to skin it
you can think of?

Thanks!

-Boris

-- 
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

boris at deepcovelabs.com

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> bounces at lists.squeakfoundation.org] On Behalf Of Avi Bryant
> Sent: Wednesday, March 21, 2007 10:42 AM
> To: Seaside - general discussion
> Subject: Re: [Seaside] Summer of Code Project
> 
> On 3/21/07, Boris Popov <boris at deepcovelabs.com> wrote:
> > Let's not forget that Avi's application is very well partitioned, so
> > taking down images and bringing them back up fits perfectly with a
model
> > of 'image-per-application'. Most other applications out there do not
> > have such boundaries, so running as many images as possible close to
> > server capacity and balancing between them is probably a better
thing to
> > do and any layer-7 load balancer should be capable of handling
session
> > affinity properly, hence the value of inventing something new might
be
> > reduced.
> 
> Even if you have a shared database between all your users (say, you
> use GLORP to access a single RDBMS), I think it's still valuable to
> keep each customer isolated in their own image (and if you're doing
> that, bringing them up and down all the time is the only way not to
> fill up your server memory too quickly).  That way anything that
> happens to one customer - an infinite loop chewing up resources, a
> #halt you add in a debugging session, a rollout of an experimental new
> feature - doesn't affect anyone else.  What you're describing is
> certainly simpler, but I do love my thousands of images...
> 
> Avi
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside