[Seaside] Seaside redirects, really?

[Sebastian Sastre]

oh that sounds cute :)

I want to take a look at the code

is available?

what should I do?

sebastian

o/




On Oct 5, 2011, at 3:12 PM, Dale Henrichs wrote:

> Sebastian,
> 
> I think that just as there is a place for static files, there is a place for dynamically generated content that does not require session state (and therefore is more performant).
> 
> With Seaside-REST it is easy to integrate RESTful urls into your Seaside3.0 application ... http://ss3.gemstone.com uses Seaside-REST for servicing requests from the Monticello Browser and full seaside for the web gui ... you get the best of both worlds ... the hits for mcz files and project listings are much more numerous than the hits on the web-site ... so there is a big savings in session state, especially since ss3 is one of those sites that do a transaction per request:)
> 
> This stuff isn't as experimental as you think...
> 
> Dale
> 
> ----- Original Message -----
> | From: "Sebastian Sastre" <sebastian at flowingconcept.com>
> | To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
> | Sent: Wednesday, October 5, 2011 10:45:39 AM
> | Subject: Re: [Seaside] Seaside redirects, really?
> | 
> | 
> | 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
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | _______________________________________________
> | 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/d37e8730/attachment.htm