[Seaside] Seaside redirects, really?

[Jon Paynter]

On Sat, Oct 1, 2011 at 10:44 AM, Sebastian Sastre <
sebastian at flowingconcept.com> wrote:

> Hi guys,
>
> please let me troll about seaside redirects...
>
> from the docs [1] one understands the basics of seaside requests
> processing:
> "...All subsequent requests are processed the same way. First, Seaside
> gives the components the ability to process the callbacks that have been
> defined during the last rendering pass. These callbacks are usually
> triggered by clicking a link or submitting a form. Then Seaside calls
> WAComponent>>updateUrl: of all visible components. This gives the developer
> the ability to modify the default URL automatically generated by Seaside.
> Then Seaside redirects the user to the new URL. *This redirect is
> important, because it avoids processing the callbacks unnecessarily when the
> user hits the Back button*. Finally Seaside renders the component tree..."
>
> so, here is what we know about seaside redirects
>
> 1. they add latency (UX on mobile seaside apps, hello?)
> 2. they complicate httpd configurations (and man! they don't need help to
> be a pain)
> 3. actually, seaside redirects complicate everything *at a questionable
> price* for *a questionable gain* (that's why I'm kicking the table about
> this)
>
> If you really care so much about state you already persisted the model,
> right?
>
> Conclusion: they're evil, they were overrated
>
> So? come on... I say seaside would be *better without them* (maybe *way*better)
>
> What you say?
>

Well ive never run into any problems with the redirects.

But speedups are always good.  What would you suggest to fix them?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20111002/8629ff74/attachment.htm