Reviving RIFE, starting work on version 2

83 views
Skip to first unread message

Geert Bevin

unread,
Jun 23, 2013, 3:04:34 PM6/23/13
to rife-...@googlegroups.com, rife...@googlegroups.com
Hi everyone,

I'm not sure at all who's still active in the server-side web development world or who's even still getting these emails, but it seemed best to reach out through the old mailing lists in case some people are interested in reviving RIFE.

I've personally been busy with a lot of other projects during the last 7 years, ranging for high-performance clustered data tools to real-time musical instruments.

I'm now working at ZeroTurnaround on the LiveRebel product and am being confronted with the state of web development nowadays. To my surprise, in many ways the approaches in RIFE are still relevant and even the Play framework is lacking quite a lot of RIFE's simplicity and power.

So, a few months ago I started work to analyze what I want to keep from RIFE version 1 to build a fresh version 2: https://github.com/gbevin/rife. I took a little break to work on another quick pet-project in the meantime (http://uwyn.com/geco/) but that's now all ready for launch.

The idea is to basically put a lot of things in question about RIFE and trim it down, throw away a lot of the junk that was accumulated and make the features very opinionated and targeted.

My initial plan of action is this:

* focus on pure Java and byte-code instrumentation, no scripting languages
* leverage the upcoming features of Java 8
* rebuild the template engine with largely the same ideas in place, but clearer and more focused
* properly finish the isolation of the continuations engine and bring it up to date
* rethink the infrastructure with IoC as a starting point, instead of having it as an afterthought
* totally rewrite the web engine, with similar principles but much more conventions and less configuration
* trim out the database abstraction layer for only certain relevant databases

I've started mocking up the new version of the template engine and took an initial stab at creating an Antlr 4 grammar. That sadly is really not working out so I've started work on a new custom parser.

One of my mistakes with RIFE v1 was that I didn't involve the community much during the development process, so I want to change that.

If you're interested in shaping what RIFE version 2 is going to become, please hop on the developers mailing list and say hi: https://groups.google.com/forum/#!forum/rife-dev

Hope to hear from some of you!

Take care,

Geert

Tyler Pitchford

unread,
Jun 23, 2013, 3:32:48 PM6/23/13
to rife...@googlegroups.com
I'm insanely busy as an attorney now, but I'm in. I miss RIFE.


--
You received this message because you are subscribed to the Google Groups "rife-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rife-dev+u...@googlegroups.com.
To post to this group, send email to rife...@googlegroups.com.
Visit this group at http://groups.google.com/group/rife-dev.
For more options, visit https://groups.google.com/groups/opt_out.



Geert Bevin

unread,
Jun 23, 2013, 5:52:04 PM6/23/13
to rife...@googlegroups.com
Great, Tyler! I'll write up docs with what I've been playing around with for the template engine revamp.

Deepak Marur

unread,
Jun 24, 2013, 2:13:10 AM6/24/13
to rife...@googlegroups.com, rife-...@googlegroups.com
Hey Geert,

This is good news !! I'm in too. Though still starting out as a newcomer to development and don't know how useful I can be, but I want RIFE out there.

Geert Bevin

unread,
Jun 24, 2013, 2:58:27 AM6/24/13
to rife...@googlegroups.com
Hi Deepak,

Thanks for stepping up, it's always very useful to get input from less experienced people since it's all too easy to make any design too complex.

Edwin Mol

unread,
Jun 24, 2013, 3:55:56 AM6/24/13
to rife...@googlegroups.com, rife-...@googlegroups.com
I enjoyed working with the first version of Rife, so I'm interested.
However, as I'm quite busy at the moment I don't know how much time I can donate, but I'll try.
Looking forward to it!

Op zondag 23 juni 2013 21:04:34 UTC+2 schreef Geert Bevin het volgende:

Geert Bevin

unread,
Jun 24, 2013, 4:03:02 AM6/24/13
to rife...@googlegroups.com
Hey Edwin,

Cool to hear again from you! I totally know what you're saying about being busy, same for me actually. To resume work on RIFE I actually now replaced my hour or two of reading in bed with hacking on the laptop :-)

Thanks for giving signs of life, I wasn't sure how many people would speak up. Three people is actually more than I expected, and I know that Brandon Hudgeons is going to pop up also, so I'm totally spiked now!

Since I'm targeting RIFE for Java 8 use (throw away the legacy stuff and leverage what's new), we have a good 10 months in front of us. With daily bite-sized efforts, it's totally doable to get a first release of v2 ready.

Take care,

Geert

David Herbert

unread,
Jun 24, 2013, 6:48:04 AM6/24/13
to rife...@googlegroups.com
Hi Geert,

I used RIFE actively for several years,  building the back end to several GIS/mapping applications.  I found it quite intuitive and lightweight (in the positive sense of the word!).  When active development stopped back in 08 I struggled to find anything as good to replace it.  I finally opted for Spring MVC (which I find unintuitive, verbose and heavyweight) but I would definitely consider using RIFE again when v2 appears.  Like other posters, I mightn't have much time to contribute on the coding front, but I would be able to become involved in reporting problems, evaluating new versions etc.

Best regards,

David Herbert.

Geert Bevin

unread,
Jun 24, 2013, 7:12:06 AM6/24/13
to rife...@googlegroups.com
Thanks David!

Actually, one of the most valuable pieces of input would be how to make RIFE v2 even lighter weight than before and much more readable to newcomers. I think that one of the main problems of v1 was that some syntaxes were a bit off-putting. Still, just as you I built a lot of very long running applications with it and when I look back at them I'm still surprised at how maintainable they are and how productive it was to write them. So for RIFE v2, the knowledge of what worked well in v1 and what was tedious is actually very valuable.

Atif Khan

unread,
Jun 24, 2013, 8:44:37 AM6/24/13
to rife...@googlegroups.com, rife-...@googlegroups.com
Geert,
   I would be willing to contribute as well in whatever capacity possible. Like everybody else, life has only gotten much busier than before. I never got to use RIFE in a real world project, but always found it to be a very intuitive framework.

Regards
Atif


On Sun, Jun 23, 2013 at 3:04 PM, Geert Bevin <gbe...@uwyn.com> wrote:

Geert Bevin

unread,
Jun 24, 2013, 8:52:18 AM6/24/13
to rife...@googlegroups.com
Thanks Atif! Just jump on whatever you see passing by when the development picks up. Currently I'm redesigning the template engine, any input on this is more than welcome:

https://groups.google.com/d/msg/rife-dev/ElyZMymk_TQ/Ko5wEIB3UmIJ

Brandon Hudgeons

unread,
Jun 24, 2013, 11:42:07 PM6/24/13
to rife...@googlegroups.com
Yep ... popping up!  :)

This is about the only project that might get me to write some Java again.  About once every 2-3 years I get a call about some production RIFE system that is still out there chugging along.  Usually, it's because a new IT guy sees an old server and takes it down, not knowing there's still an app still running, and users complain :)

Very interested to see how Java 8 changes things, and to finally learn some of your bytecode black magic.

B

Geert Bevin

unread,
Jun 25, 2013, 3:23:20 AM6/25/13
to rife...@googlegroups.com
Really great to hear from you Brandon, it was awesome meeting you in Austin last month!

As a little side-story for the others, I did start working on the RIFE Revival a few months ago but put it aside for a short while since I was just starting a new job and finishing another pet project. I was at a conference in Austin, Texas, and Brandon reacted to my tweets. So we met up in downtown Austin and he put the spark back into me tenfold. Brandon was still very enthusiastic about RIFE and had been using it successfully on many projects in the past. He never reached out much through the mailing lists though since he rarely needed any help. That got me thinking that there must be quite a few others like that, and even though the community used to be very quiet, that doesn't mean that adoption was similar.

Anyway, same for me regarding the Java 8 changes, it'll be a great opportunity to learn up and explore the possibilities.

I think it'll mostly be leveraged at first in the new web engine, which can be much simplified based on the one in RIFE v1. We're in a different world now and the presentation flow and logic on the server has to be much less than before.

Still, the key points are important I think:

* explicit data flow and logic flow between elements
* instant access to most appropriate methods (don't need to learn a whole new framework for each feature, see Spring MVC)
* easy to delve straight down to the metal
* one element instance per request, but with state that is totally isolated from other requests
* out of container testing
* minimal application restarts
* elements can be grouped in sites and behave as a single element
* elements can be embedded into templates
* web continuations
* I'm on the fence about the element 'inheritance' feature from v1, that seemed to be very confusing and not many people used it I think

One of the approaches I want to try to uphold for the new version is to remove string identifiers as much as possible. Allowing the Java compiler to do the heavy lifting and also getting implicit IDE support.

I'm also thinking of trying to come up with an event-driven design that would implicitly scale, maybe even using continuations (needs to work on serializability) as first-class citizens that are the foundation of it all. I started experimenting with a system like that a few years ago, a basic workflow engine built on top of continuations: http://svn.rifers.org/rife-workflow/trunk/ Maybe something can come out of that.

Josh Hansen

unread,
Jun 29, 2013, 3:12:19 AM6/29/13
to rife...@googlegroups.com
Hi Geert,

Nice to hear!

We're still using RIFE 1.x in our primary web application at my day job.
It's getting long-in-the-tooth with JRE 1.6 end-of-lifed, but it has
worked really well.

I'm currently busy on other projects, but I'll be watching with interest!

Josh

Josh Hansen

unread,
Jun 29, 2013, 3:40:41 AM6/29/13
to rife...@googlegroups.com
Hi Geert,

On 6/25/2013 12:23 AM, Geert Bevin wrote:
> ...
> I think it'll mostly be leveraged at first in the new web engine, which can be much simplified based on the one in RIFE v1. We're in a different world now and the presentation flow and logic on the server has to be much less than before.
>
> Still, the key points are important I think:
>
> ...
> * I'm on the fence about the element 'inheritance' feature from v1, that seemed to be very confusing and not many people used it I think

We use the authentication system, which I believe is based on the
inheritance feature. Being able to add another element to the
authentication set is really handy. We do have additional code that we
execute per-element to verify access to certain other parts of the
system, but we don't have to add code for "check authentication;
redirect to login page; return after login".

We also modified the authentication system, and it was really
challenging to figure out how it worked with triggers and all the layers
(db/memory/identity, etc).

I'm not sure if inheritance is required for that (other possibilities,
such as servlet filters?), but authentication seemed like a killer
(good) use of the inheritance feature.

Josh

Geert Bevin

unread,
Jun 30, 2013, 6:03:18 AM6/30/13
to rife...@googlegroups.com
Really great that you're still using RIFE Josh, I was sort of hoping for that since you were very active a few years ago. :-)

Geert Bevin

unread,
Jun 30, 2013, 6:08:59 AM6/30/13
to rife...@googlegroups.com
Yes, that is exactly why I'm on the fence about it.

The biggest complexity of the RIFE element inheritance feature is that it actually snap-shots request state at each layers, automatically restoring it when the triggers drop back down in the inheritance stack. It's indeed a very tricky piece of code and requires quite a bit of knowledge to use properly. Also, I think it was another feature that was very poorly named.

Like you, I have relied on it a lot in the past, but I don't know how many others did. I fully intend to keep some form of easy authentication in place, just not sure this whole infrastructure is really needed and if the state snapshotting is really needed at all.

It would be interesting to analyze what exactly is needed to many an authentication system that works just as nicely, having worked with SpringMVC quite a bit in the last few years, I do know that it should be handled at the core of a framework, otherwise it becomes a nightmare to set up.
Reply all
Reply to author
Forward
0 new messages