Smalltalk › Frameworks & Tools › Seaside › Seaside General

Seaside redirects, really?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

47 messages Options

123

sebastianconcept@gmail.co

Re: Seaside redirects, really?

oh that sounds cute :)

I want to take a look at the code

is available?

what should I do?

sebastian

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" <[hidden email]>
| To: "Seaside - general discussion" <[hidden email]>
| 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" < [hidden email] >
| | To: "Seaside - general discussion" <
| | [hidden email] >
| | 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
| | [hidden email]
| | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| |
| _______________________________________________
| seaside mailing list
| [hidden email]
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
|
|
|
|
|
|
|
| _______________________________________________
| seaside mailing list
| [hidden email]
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Dale Henrichs

Re: Seaside redirects, really?

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" <[hidden email]>
| To: "Seaside - general discussion" <[hidden email]>
| 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" < [hidden email] >
| | To: "Seaside - general discussion" <
| | [hidden email] >
| | 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" < [hidden email] >
| | | To: "Seaside - general discussion" <
| | | [hidden email] >
| | | 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
| | | [hidden email]
| | | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| | |
| | _______________________________________________
| | seaside mailing list
| | [hidden email]
| | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| |
| |
| |
| |
| |
| |
| |
| |
| | _______________________________________________
| | seaside mailing list
| | [hidden email]
| | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| |
| _______________________________________________
| seaside mailing list
| [hidden email]
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
|
|
|
|
|
| _______________________________________________
| seaside mailing list
| [hidden email]
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Dale Henrichs

Re: Seaside redirects, really?

Oh, SSUrlFilter is in the SqueakSource-Core package...

Dale

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "Seaside - general discussion" <[hidden email]>
| Sent: Wednesday, October 5, 2011 11:42:24 AM
| Subject: Re: [Seaside] Seaside redirects, really?
|
| 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" <[hidden email]>
| | To: "Seaside - general discussion"
| | <[hidden email]>
| | 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" < [hidden email] >
| | | To: "Seaside - general discussion" <
| | | [hidden email] >
| | | 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" < [hidden email] >
| | | | To: "Seaside - general discussion" <
| | | | [hidden email] >
| | | | 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
| | | | [hidden email]
| | | | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| | | |
| | | _______________________________________________
| | | seaside mailing list
| | | [hidden email]
| | | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | _______________________________________________
| | | seaside mailing list
| | | [hidden email]
| | | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| | |
| | _______________________________________________
| | seaside mailing list
| | [hidden email]
| | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| |
| |
| |
| |
| |
| |
| | _______________________________________________
| | seaside mailing list
| | [hidden email]
| | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| |
| _______________________________________________
| seaside mailing list
| [hidden email]
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

sebastianconcept@gmail.co

Re: Seaside redirects, really?

In reply to this post by Dale Henrichs

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

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

thanks Dale (I didn't knew about the docs)

sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

sebastianconcept@gmail.co

Re: Seaside redirects, really?

In reply to this post by sebastianconcept@gmail.co

On Oct 3, 2011, at 4:15 PM, Sebastian Sastre wrote:

But speedups are always good. What would you suggest to fix them?

I suggest to start treating things like any experiment, start with a proof of concept.

In practical terms, that would mean to make an heretic and shameless hack that patches all it needs in order to:
1. get rid of the redirect for every possible case
2. fix #updateUrl: so it's made without counting with redirects
3. see how it feels (measure load/latency)
4. publish results comparing regular vs. hacked

so...

for all who also want to play with this, I've opened as a project available here:

http://www.squeaksource.com/unredirect/

next step?

fix #updateUrl:

have a nice hacking

sebastian

PD: I've left it global read/write so anyone interested can commit there

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Nick

Re: Seaside redirects, really?

Hi Sebastian,

I don't get it, can't you just derive from WAActionPhaseContinuation override #shouldRedirect and use /config to set your custom continuation or set it on you application with:

myApp preferenceAt: #actionPhaseContinuationClass put: SSNonRedirectingActionPhaseContinuation.

One class, one method, one configuration setting.

I love Seaside's elegant modular and configurable design... or have I missed something

Nick

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

sebastianconcept@gmail.co

Re: Seaside redirects, really?

sure, great idea.

That non redirecting continuation class is something the unredirect package should do.*

sebastian

*then the apps should configure themselves on install or something.

On Oct 7, 2011, at 2:11 PM, Nick Ager wrote:

Hi Sebastian,

I don't get it, can't you just derive from WAActionPhaseContinuation override #shouldRedirect and use /config to set your custom continuation or set it on you application with:

myApp preferenceAt: #actionPhaseContinuationClass put: SSNonRedirectingActionPhaseContinuation.

One class, one method, one configuration setting.

I love Seaside's elegant modular and configurable design... or have I missed something

Nick

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

123