Why can't we simply build a full standalone server?

[Yann]

We have a great IDE and a great programming language : why isn't it possible to edit server scripts and build a standalone server directly from the LiveCode IDE, like in RealStudio Web Edition ? all these tricky procedures to install the LC server on a given machine aren't much in the LiveCode spirit, IMHO. Although the current approach also has its benefits, I think we really need an easier server deployment solution : assign an application ID to the standalone, double click the executable and voila...

Also, I don't understand why LiveCode users who have paid for the LC server license don't get a copy of the On-Rev desktop app for their own servers.

[mwieder]

Also, I don't understand why LiveCode users who have paid for the LC server license don't get a copy of the On-Rev desktop app for their own servers.

Well, all I can say is that you're not missing much. The on-rev client is old, buggy, and proprietary. It hasn't been updated in years. I never use it any more, just use a text editor and ftp for the script files.

[peccorinoBUSSqK9]

Thanks for your answer, anyway. I must confess that RunRev's way of managing their product development (an not only the server : the web plugin, for instance, which is still for sale but won't run on most browsers...) is making me more and more perplex.

I am considering a refund for my recent server upgrade, and a switch to another platform. Too bad, really, since I just love the language.

[FourthWorld]

We have a great IDE and a great programming language : why isn't it possible to edit server scripts and build a standalone server directly from the LiveCode IDE, like in RealStudio Web Edition ?

Have you used RB/WE?

[BvG]

You can. What you need to do to get it is a bit weird tho.

You write to support, and ask them for a version that offers cgi support. they then send to you a download link for an old LC (Rev) version, i think it's 4.0 or 3.5 or so. Those standalones can run scripts as cgi, but they need a bit of setup, and some Shared hosting sites do not have all the necessary err thingies (linux equivalent of dlls). See also this old tutorial, or my take at a basic introduction.

[Yann]

Have you used RB/WE?

Hi Richard,

Yes, I have been a RealBasic developer for many years, have tested the Web Edition several times and am buying a license right now. It's a very different product, not really suitable in its current state for creating big websites, but already impressive and increasingly powerful for prototyping and developing web apps in no time. I really wish RunRev would have taken that route for the LiveCode server, rather than their pretty anemic solution : full WYSIWYG editor for the controls, 100% RealBasic language for interface programing (not only for the logic and data management), standalone server built right from the editor, etc... but RunRev are far from that.

What impressed me at first is the testing pipeline : you just press the "Run" button like for desktop apps, your web app compiles and... the default browser launches it, without the need of any extra configuration. If port 8080 is open on your development machine, you'll be able to test the app instantly from any other machine on the network. All this, just a few minutes after installing Real Studio for the first time. No headache with Apache configuring, etc. And for the building phase, you have the choice between CGI, Fast CGI and the ready-to-use standalone server - which works with websockets by default (very responsive) and switches to Ajax if websockets are not managed by your browser.

I'm not really happy to write this here on the LiveCode forums, because I had sincere hope in LiveCode on the web. And besides, it remains a good development platform for desktop apps.

[FourthWorld]

I have been a RealBasic developer for many years, have tested the Web Edition several times and am buying a license right now. It's a very different product, not really suitable in its current state for creating big websites, but already impressive and increasingly powerful for prototyping and developing web apps in no time. I really wish RunRev would have taken that route for the LiveCode server, rather than their pretty anemic solution : full WYSIWYG editor for the controls, 100% RealBasic language for interface programing (not only for the logic and data management), standalone server built right from the editor, etc... but RunRev are far from that.

True, for database apps RB/WE is a nice toolkit.

For the LiveCode audience, however, it may not be an ideal fit, at least in terms of meeting expectations raised by the RevWeb plugin.

While a great many LiveCoders make DB frontends, there are at least as many making interactive graphical simulations, multimedia presentations, and other UIs that a RB/WE-like solution can't address.

The RevServer product takes us a step in that direction, allowing us to craft CGIs using LiveCode on the backend. In fact, I had the pleasure of using it to port a custom search engine we'd used in a desktop product to a web version, requiring only a few lines of additional code to wrap the output in HTML but otherwise it all just ran great without further modification.

While RB's being multi-threaded does indeed provide a measurable performance boost in allowing it to run gracefully under Fast-CGI, the nature of multi-threaded systems can require careful coding to avoid race conditions. The RevServer engine is single-threaded, but in practice the performance difference is relatively minor (best measured in milliseconds), and being a single-threaded CGI means that each instance is a discrete process, eliminating the potential for race conditions for the relatively low cost of a couple MBs of RAM.

True, that additional memory overhead can add up on servers with a lot of traffic, but few of us are making Google. For most of the sites of the scope we manage, RevServer performs admirably well, sometimes surprisingly so. I've made CMSes with it that are not only simpler to use than Drupal, but require 1/5th the memory and 1/20th the processing time to generate a page. Given how many thousands of devs find the resource footprint of Drupal acceptable, besting it several times over should suffice for many real-world needs.


The biggest advantage RB/WE has over LC is the integration of Web UI layout in the IDE. They do a fine job with that, and while this is the sort of thing anyone in the LiveCode community could do as a plugin if they choose, apparently the community hasn't yet found the need great enough to do so.

I've written LC->HTML translators so I have a feel for what's involved. Mine have thus far been very specialized for specific apps, and indeed it's quite a bit of work to generalize for other uses.

But as far back as '97, ToolBook provided such tools to publish to the Web, so it's not like it's a new concept or somehow impossible. Indeed, CSS has only gotten more useful since then, so the opportunity is more ripe than ever.

I keep threatening to generalize my own translation tools for this, but alas my clients have kept me far too busy to pursue it. I've been hoping some FOSS-minded soul in the LC commnity will take an interest in managing such a project; I may be able to squeeze in enough time to contribute bits here and there.

In the meantime, HTML/CSS and JavaScript aren't particularly difficult to learn, and with things like the RevIgniter framework on the backend developers can at least enjoy a workflow that exceeds the productivity possible with most PHP-base toolkits, using stuff available right now. Not quite as fluid as RB's, but far broader in terms of the types of Web apps one can deliver.

I'm not really happy to write this here on the LiveCode forums, because I had sincere hope in LiveCode on the web.

Personally, I'm very glad these forums support a diverse community with a broad range of experience, so I think your post was valuable and look forward to more from you. Diverse experience is how we all learn, and provides opportunities to encourage growth for the LiveCode platform in interesting and valuable directions.

[Yann]

Richard, sorry I didn't notice your answer sooner. Thank you very much for such an informative post.