[Seaside] Seaside redirects, really?

[Sebastian Sastre]

yeah! true!

 and preferentially with the app written in assembler using vi :)

joke aside... 

with the avoiding session-state altogether idea you're taking things a step further, I don't know if that's appealing.

It might be.

It's certainly more experimental

sebastian

o/



On Oct 5, 2011, at 2:01 PM, Dale Henrichs wrote:

> Sebastian,
> 
> If you want the absolute fastest performance, write a read only application and serve up static pages:)
> 
> If you do anything else, you will compromise your performance.
> 
> Presumably the trade offs that you make along the way are worth it.
> 
> Even in the single request model, there is a boat load of session state being saved by Seaside and that session state is a burden on the garbage collector and impacts performance ...
> 
> If you use a framework like Seaside-REST you can avoid saving session-state altogether, but then you are responsible for managing "session state" yourself ... 
> 
> There is definite value in knowing that one can arrange skipping the redirect, but it is an application-level decision whether or not the trade-off is worth it or not.
> 
> Dale
> 
> ----- Original Message -----
> | From: "Sebastian Sastre" <sebastian at flowingconcept.com>
> | To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
> | Sent: Wednesday, October 5, 2011 5:37:54 AM
> | Subject: Re: [Seaside] Seaside redirects, really?
> | 
> | 
> | 
> | 
> | On Oct 4, 2011, at 2:26 PM, Norbert Hartl wrote:
> | 
> | 
> | 
> | And still what you are saying is correct that whatever I tell you the
> | extra request goes on top. I just want to add that the effect is not
> | as big as you might think.
> | 
> | 
> | Norbert
> | 
> | 
> | 
> | 
> | perhaps, but we should rely on the measured observations on how it
> | performs with redirects vs. without them.
> | 
> | 
> | Probably not for everybody but there is something else:
> | 
> | 
> | For all people using one transaction per request kind of
> | architectures...
> | 
> | 
> | Having the redirect means that your app needs 2 transactions per
> | action with all the overhead and complications that it could mean*.
> | 
> | 
> | 
> | 
> | sebastian
> | 
> | 
> | o/
> | 
> | 
> | *for example the data your app readed fresh in the first transaction
> | has no use on the second complicating the app (if consistency is
> | mandatory it probably requires a re-read). Depending on how the app
> | deals with that problem, that could be a hidden cost (paid in
> | latency in the magnitude of I/O and in development costs)
> | 
> | 
> | 
> | _______________________________________________
> | seaside mailing list
> | seaside at lists.squeakfoundation.org
> | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> | 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20111005/f07f670d/attachment-0001.htm