[FOSS] On the creation of Rev to Web tools

[David Bovill]

On 15 September 2010 15:31, Andre Garzia <andre at andregarzia.com> wrote:

The trick is not to try to convert a
> common Rev stack, if you try to convert all kinds of Rev controls and
> stuff,
> you end up basically reimplementing the engine, this is kinda hard.


Agreed that would be hard short term, and probably doomed to fail long term.


> TWO ENVIRONMENT FRAMES
> ... Actions on the development environment do not work directly on
> the stuff we're developing but instead talk to the backend server that will
> follow the orders.
>
> WEB RUNNER CANVAS
> ... I have a Rev WebServer external ready for this
> project. Thats the second environment frame that I've mentioned above. It
> understands only Javascript.
>

I don't see any need for this approach? perhaps you need to explain a bit
more. What is wrong with getting the RevIDE to do all this client side? The
only reason to do this server side that I can see is to build a business
case around it. The RevIDe can do all this at lower cost - bandwidth etc,
and there are no real maintenance issues with distributed rev tools
nowadays. Don't get this.

WEB SAFE TOOLS PALETTE & INSPECTOR
> Replacing the tools palette with a Web tailored one with tools that we've
> scripted ourselves. They can mimic standard Revolution tools such as
> buttons
> and fields but they are not in fact creating Revolution buttons and fields
> but our own controls. We would also create our own inspector for setting
> properties of our own self made controls.
>

I think this is almost right, except that the logic of replicating Rev
controls is the wrong way round. Frankly the web controls are out of date,
and less sophisticated no than those you find in JavaScript libraries. Also
the audience and market is larger for people familiar with these existing
JavaScript interfaces than the tiny Rev market. What is needed is to emulate
the best and most robust JavaScript controls with Rev widgets - not the
other way round.

... When we drop a button on the web runner
> screen, a POST call is made to the web server that picks this and creates a
> button javascript object, this is transparent to the developer.
>

Again I can see absolutely no reason for the web server to do this - it's
more work, and what is the benefit? The dragging components onto the canvas,
can be done in the IDE. I demoed this at the last conference with widgets
that are under version control on the server.

This way Rev becomes a HTML5/JS/CSS development tool. We don't have the
> overhead of converting stacks to web because we're jumping that whole step
> working directly with HTML5 and friends. This solves control placement and
> interaction but does not solve script processing.
>

In MVC terms (as you say) - the controllers and models can be on the server.
This server side code could be on On-Rev, but equally there is no reason
when any good robust server code could be used in any language, we just need
to wrap so that the RevTalk based IDE handles it for us in the background.

As an aside, the code I've been working on is based around the idea that we
can have a more robust Rev based workflow (which speeds up native Rev
development), and has the side effect of producing server based "controller"
code - that can be ftp'd / transferred to the server and work there in
exactly the same way as it does locally. The aim is to enable the sharing of
this portable abstracted code, and build it into intuitive workflows so that
it is generated in a natural way as part of coding in Rev.

SCRIPT PROCESSING
> We would define a subset of RevTalk and create direct conversions from
> RevTalk to JS. As time went on we would implement more and more of RevTalk
> but some minimal subset should be enough for a start. Javascript is a
> wonderful language and converting scripts to it is the most safe option.
>

Yes - I think we are on the same page here. I see a sub-category of shared
code, which could be translated into JavaScript or other languages. People
would do this in order to allow their projects to work with existing online
frameworks, while allowing local prototyping in RevTalk. The workflow is
natural, and allows for gradual evolution of code bases based on incremental
incentives that benefit the end user. I think it could work, especially if
it were part of an explicit open source / open content strategy by RunRev,
in which they took and supportive but indirect role.


> The elegance of this approach is that we can begin with a fastCGI engine
> for
> the script processing by directly executing RevTalk script on the FastCGI
> process without translation....
>

I still don't see any advantage to this - maybe I am missing something? And
FastCGI is AFAIK not the way to go now anyway?

We could build this and release under BSD license which would enable
> business to use it in the commercial offerings and thus making it
> attractive
> and incentive sponsorship. .... This as it is defined needs no input
> whatsoever from the mothership, it can all be done in Rev.
>

It does not need RunRev technically, but as they are really the only ones
with a commercial incentive to make this work it works better with their
support - especially as the nature of the Rev community at present is "lone
wolf" - it is not trivial to get collaborative projects going.

With regard to the BSD style licensing - yes that is a safe bet, but I would
argue that there are better overall strategies to take which would include
BSD style licensing.