[Seaside] Seaside redirects, really?

[Sebastian Sastre]

ok, for you a ~20-40% improvement in response times isn't an incentive appealing to do anything about it. Even if that leads to an enhanced experience for the users in poor networks or using web apps from mobile devices over mediocre 3G services [1]. You made it work for your business without caring at all about that. Good for you. I have no problem with that. That's great. 

But for me is appealing enough to try to do something about it.

So, yes, understanding the design decisions matters to do "informed hacks" and see where it leads.

I found appealing to have a seaside without the redirect latency penalty [2]

sebastian

o/

[1]  there are plenty of opportunities in those markets and extra latency can put the whole framework, a priori, out of the "game" only because of that
[2] having AJAX without redirects is a step forward and is already made. Good. But not everything is AJAX. I think we can do better.


On Oct 3, 2011, at 9:01 AM, Boris Popov, DeepCove Labs wrote:

> Sebastian,
>  
> Car and airplane crashes are also a bit of an exception case, yet so much effort goes into development and testing of safety systems. I’m not sure what your end game is in this thread? If you’re trying to convince the rest of us to remove the part of the framework that’s important to a lot of people, you likely will not succeed. But if you’re trying to understand the reasons for the redirect so you can make informed decisions for your own applications, by all means.
>  
> -Boris
>  
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf Of Sebastian Sastre
> Sent: Monday, October 03, 2011 7:52 AM
> To: Seaside - general discussion
> Subject: Re: [Seaside] Seaside redirects, really?
>  
> On Oct 3, 2011, at 8:29 AM, Julian Fitzell wrote:
> Similarly the redirects serve a well
> thought purpose.
>  
> which is what exactly?
> can you describe that well thought purpose?
>  
> Decouple the callback processing from the rendering.
> 
> Thus ensuring that (a) hitting refresh doesn't re-trigger an action
> and (b) you don't get the browser dialog asking if you want to
> resubmit form data when you hit the Back button.
>  
> okay those are reasons.
>  
> Questions:
> for a: the refresh is an exception case, not the normal case, yet everything gets penalized because of that?
> for b: the browser opens that dialog only on POST requests only when the user press the back button, again an exceptional case but seaside it's penalizing every other request because of that?
>  
> sorry but that sounds right or "well thought" to you?
>  
> sebastian
>  
> o/
>  
> _______________________________________________
> 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/20111003/675bfd4c/attachment-0001.htm