LiveCode Forums.

I'm brand new to Revolution, and haven't bought Studio yet (just messing about with Media so far). Before I do, I need to know if there's a convenient way to host Revolution *applications* somewhere. Someplace where you just upload your application and It Just Works(tm).

We do not want to manage our own web server, but just to host the application somewhere, including some stored data (small amounts, <10MB in total, extremely small traffic volume). Not necessarily relational data (although that would be nice), but some kind of table data. I just need to build a quickie reporting application that a number of people would use to report their time, and what they enter needs to be stored at the server.

I had hoped On-Rev would have been something like that, but it seems not? If nothing else, $249/yr is a LOT of money for hosting this kind of app.

Thanks in advance, Peter Hjalmarsson

Peter-

You may be mixing apples and oranges here. What you want can be easily done, and I do this using on-rev, as you suggested. But "applications" in the sense that I think you're using the word here run on the user's machine, not on a server. Even revlets are things that get downloaded to the user's machine and run there. You can store the data generated from a desktop application onto a web server easily enough, but I don't think that's quite what you're looking for - it would require the user to download the rev application and run it on their machine.

On the other hand, writing your application as irev scripts that run on the on-rev server and present web pages to the user is more to the point, I think. That's how I store data into a database hosted on the server. And it's also, of course, possible to have a desktop application that communicates with irev scripts on the on-rev server to do the same. Depends on how you see the user's workflow.

mwieder, thanks for your reply. Let's see if I can be more clear with regards to what I'm looking for.

I guess I had not understood that the rev code was executed on the client for the web version, and I can see how that complicates things. I guess I hadn't though through the technical implications.

I HAD read the blurb from Rev that you can create applications that "run on PC,Mac, or over the Web", and that you can from within the tool choose to generate web, PC or Mac code from the same "source". I had hoped that you could build an application and, if properly written, you could easily deploy it as a local or web app. I'm just trying to figure out how that can be done in practice.

Another way of saying what I'm looking for is the MS Access/VB6 paradigm. You write your app and place it at a network share, and (if properly written) any user on the network can use it. Since most users these days are disconnected from the company network for most of the day, I (and probably a million other small-scale coders) are looking for something that would work similarly, but in a web environment. Maybe rev is not it - does anyone have an idea what could be then?

With regards to your tip about putting the business logic on the server side and generating HTML code. I'm sure that would work, but 1) I want to get away from "normal" web development with all it's issues and pitfalls here, and 2) the user experience of HTML pages is not what I'm looking for.

- Peter Hjalmarsson

To keep with the MSAccess analogy, the way we've done that before is to split an Access database into frontend and backend parts, where the frontend piece is on a network share or copied onto the users computer. Then the frontend communicates with the backend section (of which there is only one), which sits on a network drive and is connected to the db itself. We've done with with web frontends as well, but there's still a backend database part that lives on the server.

It's easy to do the same with rev, but you have to realize that part of this is on the user's computer and part is on the server. You can use a revlet to communicate with the server db part, but it may just be a matter of definition how far this is from "traditional" web server design.

Re MS Access solutions: Sure, splitting between frontend/backend is the standard way to minimize network traffic. Network traffic is still going to be relatively big since all table data must move over the network as you do searches and joins, which is why you need to move to proper client/server solution using ODBC or similar when the database gets big and/or you get many users. But both solutions would mean that the user needs access to the corporate network, which often is not the case these days.

At my "proper" job we mostly solve that by using Notes which has excellent support for doing online work and then re-synch. Or we just build an HTML or Java solution - with 400 000+ consultants we have the skill, the money, and recently even available staff . But then Notes is very much overkill for the hobby-type projects I'm talking about here. (My wife runs a small (non-IT) consulting company, and I'm helping her with some admin apps and other stuff.)

MS Access actually has functions for replication too, but they are comparatively messy to use.

It may or may not be easy to do it with Rev, but from what I can understand, it needs a dedicated web server. And then I could just as well use Access or VB to build the frontend and skip Rev completely. Or can I access SQL data across the internet from a Rev client without programming the whole shebang myself? And is there any way to pay for that service without going through a whole "web server/DB" deal.

I guess I'm still trying to understand what's behind the whole "build once, deploy to many platforms including the web" paradigm of Rev. Is it true it only means "you can either store the app locally or you can d/l it and run it in the browser"?

- Peter Hjalmarsson

I'm not quite sure where you're going, as I'm a little confused by the "d/l it and run it in browser" situation. This is exactly as a java or flash app behaves, running in the environment provided by the client side browser after being fed from the server. Revlets (if that's what you have in mind) work in the same way. All that is viewed in a browser window is rendered client side by the browser. What is delivered to the browser to render for display may depend on server side processing though and there are different ways of doing this. One is an on-Rev hosting situation, which you could imagine to be analogous more to php than a java or flash applet. If you want to make an app that you host somewhere on the web (instead of or as well as a desktop sort of app) then revlets are just right. When you build a standalone you can choose the option to create a version for the web which is created with a "demo" html page showing the parameters to embed in a live page hosted somewhere. You can host a revlet on pretty much any hosting service that you can lay your hands on. To store data though may be a little more involved. You can either sign up with a hosting service that provides (say) a MySQL db package, and get the revlet to write into tables on the server platform, or maybe post data to a cgi/server side engine (such as php or on-Rev) which will handle the POST data and write to a text file in a suitably sanitised location on the server, or maybe post data to a Google doc/spreadsheet. If it's a cheap and basic system you want for limited data storage, then that would probably be worth investigating.
HTH
SparkOut