RIFE is gaining increasing popularity, mainly because of it's relatively light-weight approach compared to other enterprise frameworks. What do you think of the RIFE features Geert talks about in this interview?

http://www.artima.com/lejava/articles/rife.html

hi there,

I don't see a link to any interview ?

BR,
~A

Seems the link was forgotten, here it is:
http://www.artima.com/lejava/articles/rife.html

> hi there,
>
> I don't see a link to any interview ?
>
Sorry, we added the link. Thanks for pointing this out.

The approach seems extremely complicated. Why should a developer go through all those hoops and not use something like Echo2 (simple Java-only programming without XML and other funky stuff) ?

What seems complicated?

For example here: http://rifers.org/09_stateful_counters/src/
There's no XML file in sight.


Some people like external XML declarations, some don't. You use what you need. Like for example this:
http://rifers.org/08_advanced_continuations/src/

What does a checkout process. The XML hardly seems complex to me.

Regarding using continuations for web applications: This is definitely a controversial subject (The following article gives a good summary of issues involved: http://www.interact-sw.co.uk/iangblog/2006/05/21/webcontinuations), and some argue that it just doesn't fit an event-driven system like the web, very well.

The RIFE article goes back in time (to give an analogy of continuations to the linear model of input/output in pre-GUI/web era), and, well, let's, and let's move forward from there:

It's clear what disadvantages such linear models give: You can't easily abandon something midway, and do something else, or do things in a different order.

Then came GUIs and liberated us from such strict ordering: Now we can fill in forms in any order we want, set options at any time, start something halfway, then come back later, branch out into multiple tasks, etc.

To program this required a fundamentally different way of programming: Rather than print a prompt, wait for input, then print the next prompt, and so on, you instead need to be prepared for essentially _anything_, in any order. For that, event-driven programming have been found to be a much better fit, where you wait for events, respond to it, wait for the next event, and so on.

I'm wondering if Geert, or someone else, would care to address some of the concerns of the article at the above link, and in particular, I'm wondering if using continuation-style programming on the web - especially in the presence of abandoned sessions, branching, thread issues, etc. - might actually make it a harder model to work with, than the usual event-based model.

Hi Terje,

this is a very good point. Actually to go back in time is a lot easier with continuations than with traditional models since each step is a snapshot that can be restored at any given time. You thus can totally freely go back, branch out, use multiple browser windows, ... All this just works without having to worry about it as a programmer. In fact, it's one of the most alluring features of continuations for web programming. If you want, just try this out with the examples at http://rifers.org/examples

Another thing to point out is that RIFE allows you to do continuations on a component level. A component can be a small area of a page that works with all the regular event handling still available. You can even have several continuations conversations that are active on the same page at once.

Does this answer your question?

Best regards,

Geert

Again regarding continuations for web applications: I think quoting from the conclusion of the article mentioned in my other post may be useful, as it enables people to know the essence of what it says, without having read it:

"My final objection is a bit more abstract: I think it’s a mistake to choose an abstraction that badly misrepresents the underlying reality. We made this mistake with various distributed object model technologies last decade. I think the attempt to model a user’s path through a web site as the sequential execution of code is at least as misguided. Users don’t necessarily take a single linear path through a web site, so code execution is completely the wrong shape of abstraction."

Hi Geert, and thanks for a very fast reply.

> this is a very good point. Actually to go back in time is
> a lot easier with continuations than with traditional
> models since each step is a snapshot that can be restored
> at any given time. You thus can totally freely go back,
> branch out, use multiple browser windows, ... All this
> just works without having to worry about it as a
> programmer. In fact, it's one of the most alluring
> features of continuations for web programming. If you
> want, just try this out with the examples at
> http://rifers.org/examples

Thanks for the link, I'll look into them. I browsed over the various examples, yet, I'm wondering how one would write code for something like this quite typical (I'd think), but simplified, scenario:

You may go to an online bookstore, find any books you want, and start the checkout process. Then you realise that you wanted to change something, and since this site won't let you go back, once the checkout is started (Amazon is like that, for example), you open a new window/tab, go to your "shopping cart", do any changes, and perform checkout from there.

What happens to the process in the "abandoned" checkout? Is it "garbage collected", and how might you do any "rollback", if that might be an issue in this case?

In your experience, have you come across scenarios that have proved difficult to model with continuations (just as there may be scenarios that may be difficult to do in non-continuation style)?

> What happens to the process in the "abandoned" checkout?

Or perhaps more importantly, what happens if you _do_ complete that path, too? You may then end up with _two_ checkouts for the same order, which is clearly nonsense.

It seems to me that this means - as it says in the article I linked to - that you now have to deal with concurrency in your control flow, as well. A partway done checkout may have to be abandoned halfway through, as another "thread" did a checkout, instead.

Sure, you "only" need to check for such conditions is at the "yield" points, but...

I guess one good way to find out whether or not this may "fly", is to implement some non-trivial functionality using either approach, and see how it turns out.

It seems the ability to do trackback and branching, in your framework, makes this a less linear approach, and rather instead a more tree-shaped kind, which may fit (web) applications better than the linear kind.

> You may go to an online bookstore, find any books you
> want, and start the checkout process. Then you realise
> that you wanted to change something, and since this site
> won't let you go back, once the checkout is started
> (Amazon is like that, for example), you open a new
> window/tab, go to your "shopping cart", do any changes,
> and perform checkout from there.

What is your question about here? Do you wonder about the possibility of opening up a new window, of temporarily interrupting the checkout process and still resume afterwards with new data in the cart, or to invalidate an active checkout process when you changed your cart elsewhere?

> What happens to the process in the "abandoned" checkout?
> Is it "garbage collected", and how might you do any

Indeed it is. You can setup the collection time-out yourself and by default in RIFE it is 20 minutes.

> "rollback", if that might be an issue in this case?

What you typically do instead of having to roll back is having a process that only commits the change once that particular linear flow is finished. When that is done, you write the data to the back-end and explicitly throw away all the continuation steps in the active conversation so that the user can't submit the same data twice.

> In your experience, have you come across scenarios that
> have proved difficult to model with continuations (just as
> there may be scenarios that may be difficult to do in
> non-continuation style)?

Sure there are plenty. Actually, I only advocate the use of continuations when there's a clear linear progression. I call there 'islands of functionality'. All the rest should be done with a tradional event-based system.

> Or perhaps more importantly, what happens if you _do_
> complete that path, too? You may then end up with _two_
> checkouts for the same order, which is clearly nonsense.

As soon as one succeeds, you can invalidate the entire continuation tree and the other ones that are in progress simply become disfunctional and snap back to the location before the continuation conversation was initiated.

> > You may go to an online bookstore, find any books you
> > want, and start the checkout process. Then you realise
> > that you wanted to change something, and since this
> site
> > won't let you go back, once the checkout is started
> > (Amazon is like that, for example), you open a new
> > window/tab, go to your "shopping cart", do any changes,
> > and perform checkout from there.
>
> What is your question about here?

The question came at the start of the next paragraph (what happens to the abandoned checkout?), which you reply to below.

> Do you wonder about the
> possibility of opening up a new window, of temporarily
> interrupting the checkout process and still resume
> afterwards with new data in the cart

Yes, I thought of that one after posting this, thus my follow-up posting. :)

> , or to invalidate an
> active checkout process when you changed your cart
> elsewhere?

I guess that's part of the same problem.

> > What happens to the process in the "abandoned"
> checkout?
> > Is it "garbage collected", and how might you do any
>
> Indeed it is. You can setup the collection time-out
> yourself and by default in RIFE it is 20 minutes.

Ok.

An interesting alternative implementation is to store the continuation state on the client, in an article I just came across (http://ezrakilty.net/research/2006/05/web_continuations_not_so_harmful.html).

> > "rollback", if that might be an issue in this case?
>
> What you typically do instead of having to roll back is
> having a process that only commits the change once that
> particular linear flow is finished.

That makes sense (whether or not one is using continuations, also).

> When that is done, you
> write the data to the back-end and explicitly throw away
> all the continuation steps in the active conversation so
> that the user can't submit the same data twice.

Ah, ok. That answered my follow-up posting. :)

> > > You may go to an online bookstore, find any books you
> > > want, and start the checkout process. Then you
> realise
> > > that you wanted to change something, and since this
> > site
> > > won't let you go back, once the checkout is started
> > > (Amazon is like that, for example), you open a new
> An interesting alternative implementation is to store the
> continuation state on the client, in an article I just
> came across
> (http://ezrakilty.net/research/2006/05/web_continuations_no
> t_so_harmful.html).

There are a lot of disadvantages to storing continuations on the client-side.

First, since the local variable state is automatically captured, there's a security issue to be concerned about. There's a real risk for sensitive data to be inadvertedly pushed to the client.

Second, serializing complex data structures is not trivial and many developers get the implementation wrong. Even if that is the case, ensuring that it correctly is maintained when data structures change over time is very resource intensive. That's why we opted to not enforce that on the developer and to merely rely on clonability if the previous states need to be preserved. To get scalability and fail-over, we're now working with Terracotta to make this very easy (http://rifers.org/blogs/gbevin/2006/5/25/continuations_clusterable).

Third, serialization and deserialization of state to the client-side is very cpu hungry. This doesn't really make sense if the data has no real use on the client-side (like with RESTful sites).

I thus don't see much benefit in this when the state is automatically captured.