Rev Advances on Desktop and Server
How does the Rev platform move forward from here?

by Mark Waddingham

I know many of you have questions in regard to all the Rev products so I have put some of them to our CTO Mark Waddingham, and he has kindly taken the time to give us some answers.

How does the Rev platform move forward from here?

Well I think the most important thing to remember is that Rev was around long before revMobile was announced and, indeed, is only one product in our ecosystem. Rev is and will continue to be available in all its other forms, including deployment options for desktop, web and server. Indeed, revMobile is not going away although will (for the immediate future at least) have more modest goals than perhaps we had hoped.

Now, without an Apple AppStore-capable version of revMobile on the horizon it is true we have had to seriously look at our development plan for the coming year and restructure it. Our resource situation is a little more constrained and a number of pieces of engineering we were committed to whose only purpose was to make revMobile AppStore-compliant will now not be necessary.

As a result, we are hoping to deliver some significant new functionality in both our Desktop and Server offerings sooner than we perhaps might otherwise have done.

Thats very good to hear, so if we can be a little more specific, what do you see happening in the next releases of desktop Rev?
 
Well on that front I have some good news and, unfortunately, a small bit of (superficially) bad news.

We have been working on 4.5 and apart from a number of irritating regressions (fixed for dp-4) it is looking really good. Unfortunately, with recent events I have had to make the decision to move the improved field from 4.5 to 5.0 (there are some very good technical reasons for this which I'll explain next). We are, however, making really good progress on the web-plugin and hope an improved version of this will debut before much longer. We are looking to ship 4.5 as soon as the improved web-plugin is ready.

Now, one of the key pieces on the original road to revMobile was to re-engineer the engine to work with unicode strings transparently. This remains a vital piece of engineering that not only brings immense benefits to users, but also vastly improves the engine internals and is an enabler for a number of other things down the line. The simple fact is that *everybody's* lives are made easier by doing this as soon and as quickly as possible.

As you can probably imagine moving to unicode strings is going to involve a significant number of changes to the source-base. Now, having done a lot of ground-work I am sure that we can now do this relatively quickly - however, it can *only* be done at a stable point in our release life-cycle. We have effectively reached such a point with 4.5 as it is now. Therefore, we will be doing Unicode and *then* integrating the new field - delivering both together in a solid 5.0 release.

When do you think we will see the next dp release for 4.5?
 
To use a potentially over-used phrase - 'real soon now'. The engine and IDE are in good shape and we are now just putting the finishing touches to our new installer that we intend to roll out with 4.5-dp-4.

How about revServer? Will that be moving forward?
 
Yes - we are bringing forward our revServer development plan so that we push this to get to release quality as the 'next big thing' after version 5.0 and its transparent Unicode support.

What specific new features do you expect to implement for on-Rev/irev?

Well stack support is certainly one. We'll be making it so that stacks will sit in a (slightly modified) message path just as you get in desktop Rev; you'll be able to store and load them and (all being well) take snapshots of objects and controls to produce images.
 
We will be adding native support for things such as cookies and sessions. Of course you can use these at the moment, but you have to code the mechanisms yourself, we fully intend to provide more 'rev-like' access to such features.
 
With further development on revServer coming after the new Unicode functionality, it will be a key goal to make irev scripts 'text encoding agnostic'. Basically, revServer will 'do the right thing' regardless of what text encodings you use to write your web-pages in; and you'll have choice as to what encoding is served to the user's browsers.

Will we be getting revServer released for those who want to install it on their own servers?
 
We'll be announcing plans for a revServer product you can install on your own server shortly.

What about Linux support?

We will be looking at improving support for Linux in various areas, including bringing the web-plugin to Linux for the first time.

How is the timescale of all this impacted by the change in direction for revMobile?

We are working tirelessly to try and achieve as much as we can as quickly as we can. We'll be making more timescale information available to our revEnterprise customers soon.

Can you tell us anything about your plans for the Android platform?
 
Clearly Android is the fastest growing smartphone target, and it is almost certain that it (as a platform) will over-take iPhoneOS over the course of the next year. You can be sure that we are exploring all our options for this platform aggressively. I really can't say much more on this right now except - watch this space.

So you would say that in some ways this change in direction is not all bad?

Well I can certainly say that I think we'd all rather not have had to make this change in direction! However, I'm a firm believer in 'every cloud has a silver lining' and the silver-lining in this instance is that our Desktop, Web and Server will be getting significantly more attention sooner than they would have otherwise. It also means we get to explore possibilities in the Android space sooner, a platform that is turning out to be very exciting from a developer perspective. So yes, its a bump in the road, but we have a great plan and a great future. We're all looking forward to bringing that to you.

About the Author Mark Waddingham is CTO for Runtime Revolution Ltd.