[Seaside] Seaside redirects, really?

Wed Oct 5 18:42:24 UTC 2011

Sebastian,

Seaside-REST is documented here[1]. If you want to see what was done for SqueakSource3, look at the SSUrlFilter class[2].

Dale

[1] http://code.google.com/p/seaside/wiki/SeasideRest
[2] http://www.squeaksource.com/squeaksource3.html

----- Original Message -----
| From: "Sebastian Sastre" <sebastian at flowingconcept.com>
| To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
| Sent: Wednesday, October 5, 2011 11:27:58 AM
| Subject: Re: [Seaside] Seaside redirects, really?
| 
| 
| 
| 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
| 
| 
| 
| 
| 
| 
| _______________________________________________
| seaside mailing list
| seaside at lists.squeakfoundation.org
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| 