|
Posts: 135 / Nickname: fsommers / Registered: January 19, 2002 7:24 AM
The Philosophy of RIFE
August 15, 2006 9:00 PM
|
|
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 |
|
Posts: 2 / Nickname: anjanb / Registered: March 13, 2002 6:29 AM
Re: The Philosophy of RIFE
August 16, 2006 11:28 AM
|
|
hi there,
I don't see a link to any interview ? BR, ~A |
|
Posts: 10 / Nickname: gbevin / Registered: August 11, 2006 5:38 AM
Re: The Philosophy of RIFE
August 16, 2006 11:32 AM
|
|
Seems the link was forgotten, here it is:
http://www.artima.com/lejava/articles/rife.html |
|
Posts: 135 / Nickname: fsommers / Registered: January 19, 2002 7:24 AM
Re: The Philosophy of RIFE
August 16, 2006 1:09 PM
|
|
> hi there,
> > I don't see a link to any interview ? > Sorry, we added the link. Thanks for pointing this out. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: The Philosophy of RIFE
August 17, 2006 8:58 AM
|
|
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." |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: The Philosophy of RIFE
August 17, 2006 8:36 AM
|
|
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. |
|
Posts: 10 / Nickname: gbevin / Registered: August 11, 2006 5:38 AM
Re: The Philosophy of RIFE
August 17, 2006 8:56 AM
|
|
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 |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: The Philosophy of RIFE
August 17, 2006 9:13 AM
|
|
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)? |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: The Philosophy of RIFE
August 17, 2006 9:31 AM
|
|
> 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. |
|
Posts: 10 / Nickname: gbevin / Registered: August 11, 2006 5:38 AM
Re: The Philosophy of RIFE
August 17, 2006 9:39 AM
|
|
> 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. |
|
Posts: 10 / Nickname: gbevin / Registered: August 11, 2006 5:38 AM
Re: The Philosophy of RIFE
August 17, 2006 9:36 AM
|
|
> 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. |
|
Posts: 33 / Nickname: tslettebo / Registered: June 22, 2004 8:48 PM
Re: The Philosophy of RIFE
August 17, 2006 9:56 AM
|
|
> > 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. :) |
|
Posts: 10 / Nickname: gbevin / Registered: August 11, 2006 5:38 AM
Re: The Philosophy of RIFE
August 17, 2006 1:45 PM
|
|
> > > 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. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: The Philosophy of RIFE
August 17, 2006 2:36 AM
|
|
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) ?
|
|
Posts: 10 / Nickname: gbevin / Registered: August 11, 2006 5:38 AM
Re: The Philosophy of RIFE
August 17, 2006 2:49 AM
|
|
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. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: The Philosophy of RIFE
August 18, 2006 1:57 AM
|
|
> 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. Personally, I am against code existing in files outside source code files; and encoding my program's flow in markup files like xml (or even worse, jsp) is just that. I want to be able to control my code, and not the other way around. Maybe I am mistaken, but going through all the examples reveals that xml is plenty. Especially revealing is the numberguess game, because Echo2 has exactly the same example, and I can make direct comparisons. Overall, here is my initial thoughts about the RIFE approach: 1) using non-source code files to encode application flow is bad. With Echo2 (used here as an example, not praised as the final solution to everything), I don't have to write external stuff, and the compiler can happily validate the code. Even if I encode the application flow entirely with Java (file site.java), it seems pretty strange. Echo2 feels much more natural, like writing a Swing application. 2) RIFE templates can hapilly be Echo2 Java component classes. What is better than reusing a class? 3) the Echo2 approach seems safer because there is no string management with templates: all the string manipulation takes place behind the programmer's back. 4) I need to learn a lot of things even before starting reading the documentation (portlets, metadata, elements, flow language, etc). I just do not see what the fuss is all about and why things are to be so complicated. The web browser is just another GUI client, like Swing or X-Windows. I prefer to keep things simple, and a framework like Echo2 gives me the simplicity I need. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: The Philosophy of RIFE
August 18, 2006 2:00 AM
|
|
I forgot to add my opinion about continuations: I do not see how they are necessary, in the context of an event-driven GUI (again, like Echo2). Maybe they are necessary when the user has the choice to make a mess of the application using the browser controls...
|
|
Posts: 10 / Nickname: gbevin / Registered: August 11, 2006 5:38 AM
Re: The Philosophy of RIFE
August 18, 2006 3:59 AM
|
|
Achilleas,
I think this very dependent on the application that you're developing, the intended users and the preferences of the developers. I for one don't look at web applications as just another GUI client with the same event model as desktop applications. To me they are totally different, with their own interaction model and UI guidelines. I have many times noticed that users of public sites don't understand a rich interaction model in a web site. This is the most important thing that is holding true RIA applications back. However, when creating a RIA, we much prefer to do that in OpenLaszlo with REST web services in the back-end, but to each his own. Also, most websites are still informational or community-based and not desktop-like applications. A Swing model doesn't feel right at all to me in these cases. For the applications that we develop it's extremely important to have total control over the URLs since we have to localize them, to intelligibly use the pathinfo, ... It's also of capital importance that HTML and Javascript stay 100% isolated in dedicated files and stay as close as possible to the files that designers deliver. Additionally, total control of the state management is something that you can't neglect when creating meaningful URLs or RESTful applications. The concepts that one has to learn for all this don't go away, and things like meta-data, componentization, flow and state handling, ... will have to be dealt with sooner or later. I think we might just have to agree to disagree on this one. This is the case why there are so many alternatives out there. One solution can't be right for everyone. Best regards, Geert |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: The Philosophy of RIFE
August 21, 2006 2:09 AM
|
|
> I think this very dependent on the application that you're
> developing, the intended users and the preferences of the > developers. Indeed, but most apps have some common ground, especially apps with a user interface (i.e. most apps today). > > I for one don't look at web applications as just another > GUI client with the same event model as desktop > applications. To me they are totally different, with their > own interaction model and UI guidelines. There is no conceptual difference between a web application and a desktop application from a user-interface point of view: they both show some information to the user, along some commands to modify the information. The differences you mention are a result of different technology, not different needs. > It's > also of capital importance that HTML and Javascript stay > 100% isolated in dedicated files and stay as close as > possible to the files that designers deliver. That is a techical artificial constraint. Your designers could simply deliver files that describe the web pages which you could convert to Java classes. It is no different than someone designing a Qt form with Qt designer and me (the programmer) importing it in the application. > Additionally, total control of the state management is > something that you can't neglect when creating meaningful > URLs or RESTful applications. The concepts that one has to > learn for all this don't go away, and things like > meta-data, componentization, flow and state handling, ... > will have to be dealt with sooner or later. I can not disagree with this, in the context of a URL-driven application. But the above is not a issue in Ajax-driven applications. And the RIFE examples are perfect candidates for AJAX-driven applications; they are not 'simple informational web sites'. > > I think we might just have to agree to disagree on this > one. This is the case why there are so many alternatives > out there. One solution can't be right for everyone. > Of course! it goes without saying. Thanks for replying. |
|
Posts: 10 / Nickname: gbevin / Registered: August 11, 2006 5:38 AM
Re: The Philosophy of RIFE
August 21, 2006 4:59 AM
|
|
There is no conceptual difference between a web
> application and a desktop application from a > user-interface point of view: they both show some > information to the user, along some commands to modify the > information. I don't agree with that at all. In a desktop application you're not supposed to be able to access any intermediate step (page / url) directly. You don't bookmark them and you certainly don't pass the locations around. You don't have to deal with latency issues when performing UI interactions. You don't have to handle the fact that there should be printable versions of most pages. You don't have to be paranoid about who's using the application or about privacy since you can mostly rely on the OS security model. You don't have to deal with different browsers that render the same information, nor do you have to handle the fact that people can disable essential features like Javascripts, Java, Flash, Images, ... I can continue a long time like that. Apart from all these, a lot of people expect different things from websites than what they expect from desktop applications. I have seen from experience that apart from very well defined applications (like web mail, chat, ...). Most site visitors don't understand what they can do with a web UI that functions (almost, but not quite) like a desktop UI. A lot of people are totally lost. This makes sense, since it's essentially an information architecture that's now being migrated to new functionalities that are many times just bolt-ons. Almost none of the habits that took them years to acquire to work with desktop applications can be applied, so why would they understand the UI? > That is a techical artificial constraint. Your designers > could simply deliver files that describe the web pages > which you could convert to Java classes. It is no > different than someone designing a Qt form with Qt > designer and me (the programmer) importing it in the > application. That is wishful thinking and I've never seen any complex web design that doesn't need carefully crafted HTML, CSS and Javascript to be able to work on the majority of browsers. > And the RIFE examples are perfect candidates for > AJAX-driven applications; they are not 'simple > informational web sites'. Well, they are trivially simple, tightly packaged examples do demonstrate specific functionalities. Take care, Geert |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: The Philosophy of RIFE
August 24, 2006 2:45 AM
|
|
> I don't agree with that at all. In a desktop application
> you're not supposed to be able to access any intermediate > step (page / url) directly. You don't bookmark them and > you certainly don't pass the locations around. Choosing a specific page to view is no different than choosing a specific window from a list (as a concept, not as an implementation). But most web applications, especially intranet ones, are most like desktop apps rather than what you describe. And even if the app needs to be like that, again there is no need to mess with non-code. > You don't > have to deal with latency issues when performing UI > interactions. It depends on the interactions. > You don't have to handle the fact that there > should be printable versions of most pages. A printable version of a page means the page is informational only - hardly an application. > You don't have > to be paranoid about who's using the application or about > privacy since you can mostly rely on the OS security > model. That's irrelevant to how you code the application. You don't have to deal with different browsers that > render the same information, Exactly. Using an API prevents you from doing that. But the point of this discussion is 'what API'. An all-Java API (where 'Java' can be substituted with your language or preference) is certainly easier to handle than several different languages. > nor do you have to handle the > fact that people can disable essential features like > Javascripts, Java, Flash, Images, ... I can continue a > long time like that. Again, the API can take care of that. > > Apart from all these, a lot of people expect different > things from websites than what they expect from desktop > applications. I have seen from experience that apart from > very well defined applications (like web mail, chat, ...). > Most site visitors don't understand what they can do with > a web UI that functions (almost, but not quite) like a > desktop UI. A lot of people are totally lost. Oh, come on. You are exagerrating. Most computer users are able to use almost all functions after a while in a well-designed application, either web or desktop. > This makes > sense, since it's essentially an information architecture > that's now being migrated to new functionalities that are > many times just bolt-ons. Almost none of the habits that > took them years to acquire to work with desktop > applications can be applied, so why would they understand > the UI? I disagree. The habits of clicking commands, writing text, clicking to focus, opening and closing forms is just the same in web and desktop apps. > That is wishful thinking and I've never seen any complex > web design that doesn't need carefully crafted HTML, CSS > and Javascript to be able to work on the majority of > browsers. Why don't you check out Echo2 then? I am not in anyway advertising it, but it is the only Java API I know that does not require anything else than Java. |
|
Posts: 27 / Nickname: tblanchard / Registered: May 11, 2003 10:11 AM
Re: The Philosophy of RIFE
August 25, 2006 0:31 PM
|
|
Choosing a specific page to view is no different than choosing a specific window from a list (as a concept, not as an implementation). But most web applications, especially intranet ones, are most like desktop apps rather than what you describe. And even if the app needs to be like that, again there is no need to mess with non-code.
Not true. Users can submit a form, hit the back button, change a value, then submit it again. You can prevent that in a desktop app. As to continuations based development - I do everything in seaside these days and it is MUCH easier to deal with the web using continuations than it is without. http://seaside.st |