Continuations - their future?

Hello,

I'd like to hear what people have to say about the future of  
continuations in Seaside. I saw a comment from Avi a while ago, that  
has been reposted numerous times in various blogs, which said that  
continuations should be dropped because they can be replaced by Ajax  
and would allow support for Strongtalk.

For me, I'm just getting my feet wet with Seaside and a big reason  
for my interest in the framework is because it *does* support  
continuations. In my heart of hearts, I'm hoping those words were  
taken a bit out of context and things are different now but please  
let me know. I couldn't find additional material on this in the  
archives, at least none that jumped out to me.

I come from a WebObjects background where continuations reign  
supreme, they're called "component actions" in WO lingo. You could  
always create a "direct action", and there are times for it, but  
mostly it just makes more sense to use the continuations approach.  
Almost all web frameworks support "direct actions", those are just  
the urls with a query string of varName=value pairs separated with an  
ampersand. The continuations giving a context to work with makes web  
programming almost like traditional programming. It's nice. No need  
to expose those query strings or generate them either.

In the beginning, when Ajax hit the scene and WO developers started  
dabbling, you had to use "direct actions". Just because we hadn't  
figured out how to deal with all the partial page loads and prevent  
running out of your backtrack cache. Those problems have been solved  
and it is now easy to use "component actions" with reusable Ajax  
components. I'm hoping the same is true with Seaside.

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

On 12/9/07, Aaron Rosenzweig <[hidden email]> wrote:

> For me, I'm just getting my feet wet with Seaside and a big reason
> for my interest in the framework is because it *does* support
> continuations. In my heart of hearts, I'm hoping those words were
> taken a bit out of context and things are different now but please
> let me know.

<snip>

> I come from a WebObjects background where continuations reign
> supreme, they're called "component actions" in WO lingo

Aaron,

Let me clear up a couple of points of confusion here.  First of all,
I've never advocated removing continuations from Seaside, simply
making them optional.  I believe that's already true as of 2.8.  I
have indeed said that I find them much less important now than they
were pre-Ajax, but they have their uses and there's no reason to get
rid of them.

Second, WebObjects does not (and cannot) have continuations in the
Seaside sense.  The "component actions" in WebObjects map most closely
to what we call "callbacks", and those are absolutely foundational in
Seaside - it makes little sense to think about the framework without
them, Ajax or no.  Continuations only come into play when you use
#call: and #answer: between components, which has no equivalent in WO.

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

Thanks Avi,

That does help. I have a lot to learn. That's a good thing :-)

Thanks again,
-- Aaron

On Dec 9, 2007, at 11:16 PM, Avi Bryant wrote:
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/12/10, Avi Bryant <[hidden email]>:
No, that is unfortunately not yet the case for 2.8. The amount of
continuations used has simply been reduced. It is not yet possible to
run continuationless with CPS (#show:during:) which is a problem for
the VAST port.

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

Hello Guys!

I'm really interested in following:

If the future of seaside is AJAX how can you explain me words of  
Lucas: He said me that i should use AJAX to update only one DOM  
object, if there is a complex task it is much better to refresh all  
page.

Why should we put off call: answer: chain for the AJAX? Or we don't?  
How will back button work?

I've come to seaside just a half year ago and now i have a good  
project on it. But i really want this project to have a future. I  
don't want to work with a little different Ruby on Rails. Maybe i  
don't understand something? If so, please, explain me. I want to know  
future of tech i am working with.


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

> If the future of seaside is AJAX how can you explain me words of
> Lucas: He said me that i should use AJAX to update only one DOM
> object, if there is a complex task it is much better to refresh all
> page.

What I tried to express is that if you try to update 100 tiny DOM
elements as part of an AJAX request you certainly run into troubles.
It is much easier to update a single big part with as many enclosed
DOM nodes as you want.

> Why should we put off call: answer: chain for the AJAX? Or we don't?

No nobody ever proposed that.

> How will back button work?

With AJAX this is difficult, in fact I have not seen a working
solution. For normal HTTP we have pretty decent stuff that is going to
be supported in the future too.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Oleg,

        interesting question. I was searching for an answer of AJAX and
backbutton in Seaside. Yahoo user interface library have this History
Manager that helps with that. But "the hole is deeper".

        Every nifty js library and ajaxification of web apps should trigger
a big warning about how much the use of that resource will deteriorate your
old fashioned development speed. Your ROI can be easily compromised if bad
choices are made on a compromise with a non mature technology made too
early.

        Bad choices can too easily happen in our industry because we not
only have to understand how the technology works and is used to build
sofware artifacts regarding to the demand but also it's economy. In this
matter my rule of thumb for todays (2007) is: too much AJAX can harm your
ROI.

        In short words Lukas said that a full render is better than a
complex multi component updater. You can even make tests to see which is
faster and surprise yourself.

        Http lacks of events coming from the server to the client (paliated
by hacks like comet) that will also can make a big difference on seaside
development because of having the models in the servers and the presenters
in the user agent. But again, todays is just too new, maybe is not stable or
secure or scalable as you may need and you will have to include the
operative costs of making that work for you harming your ROI.

        So, I'm enthusiast when I can risk and conservative when cannot. We
all enjoy inventing the future but a solution meant to last long, has to be
deeply ponderated and experimented to achieve a solid fundation. Otherwise
it probably never had too much value.

        Seaside already has the most powerfull backtrack and simple style of
development for web. Why don't exploit it as much as you can and see what
happens?

        cheers,

Sebastian
       

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

>  It is not yet possible to
> run continuationless with CPS (#show:during:) which is a problem for
> the VAST port.

Hi Philippe

is it the goal to make the code of seaside tail-recursive (CPS) (just  
the call:answer:)?


Stef

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

> is it the goal to make the code of seaside tail-recursive (CPS) (just
> the call:answer:)?

This is already possible. Instead of #call: you use #show:onAnswer:,
where the first argument is the same and the second argument is the
rest of the computation (a block). Doing it manually leads to
extremely ugly code, doing it automatically would hide this code but
it is not easily possible in a platform independent way.

There are a few other internal places where Seaside uses
continuations. We could get rid of those, but it would require some
major changes in the internal architecture of Seaside.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

thanks.
This was just my curiosity.
I like seaside the way it is :)

Stef

On 11 déc. 07, at 18:55, Lukas Renggli wrote:
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside