Rev and the Web, feedback wanted.

Are you using LiveCode to create server scripts or CGIs?

Moderators: Klaus, FourthWorld, heatherlaine, robinmiller, kevinmiller

Bernard
Posts: 184
Joined: Sat Apr 08, 2006 10:14 pm
Location: London, England

Post by Bernard » Tue Dec 05, 2006 12:25 am

It makes no doubt that Scott Raney was really no java afficionado
Marielle, I'm not sure what you mean by that statement. Looks to me like there's a typo in there. Anyway, I went off to read that thread to which you linked.

I don't know Scott Raney from Adam, but for sure he was no fan of Java. When we consider what the world looked like in 1996, I'm sure he thought it was a desperate mistake to try to add RIA features to web pages by using Java Applets. History has proven him right about the totally misguided nature of Java Applets. Heck, I've done Java programming and even now 10 years since 1996, a 40 fold increase in the speed of my internet connection, and god knows how much faster CPU, even I will often close a browser window than wait for some damn applet to load.

It's generally accepted that Java was a disaster except on the server side. And even there there was much over-engineering in J2EE. A lot of the popularity of ROR has come from disenchanted Java programmers who felt the pain of developing J2EE web apps (of course, many people were using J2EE who didn't need that kind of infrastructure).

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Post by marielle » Tue Dec 05, 2006 1:09 am

Bernard wrote:I don't know Scott Raney from Adam, but for sure he was no fan of Java.
Sorry for the confusion. That's what I intended to write. Afficionado n : an ardent follower [syn: fan, buff, devotee, lover] online dictionary

Scott Raney is the person who wrote metacard, from which revolution is derived.
Bernard wrote:History has proven him right about the totally misguided nature of Java Applets. Heck, I've done Java programming and even now 10 years since 1996, a 40 fold increase in the speed of my internet connection, and god knows how much faster CPU, even I will often close a browser window than wait for some damn applet to load.

It's generally accepted that Java was a disaster except on the server side. And even there there was much over-engineering in J2EE.
I don't disagree at all ;-)

Bernard
Posts: 184
Joined: Sat Apr 08, 2006 10:14 pm
Location: London, England

Rev and Java

Post by Bernard » Tue Dec 05, 2006 12:50 pm

Just to show I'm not entirely anti-Java (I think there are ways it can be useful). Here is the quote that kinda ended that discussion between Scott and the Java proponents:
It all depends on how you look at things. Here is a simple, objective
test using the Scientific Method:
Hypothesis:
"Java is a better language for building Web servers
in than MetaCard."
Contrary Proof :
1. Metacard is the best programming language in the world.
2. Web Server writers try to use the best programming
languages.
3. There is a web server written in MetaCard.

Well, 3 doesn't seem to hold up. Let's try a positive proof.
Proponent(?) Proof :
1. Java is the best programming language in the world.
2. Web Server writers try to use the best programming
languages.
3. There is a web server written in Java

Well it seems like there are actually two web servers written in Java,
one by Sun and one by a neutral third party (W3C). I think the second
proof is more compelling. How about it Scott?

Now if your yelling and screaming "But MetaCard isn't for writing
Web servers in stupid, its for doing cool GUI tools." then the second
point is made as well. Java isn't your competitor, and it could be
your ally if you pick the winning strategy.
What I think is pertinent to Andre's project is not the provision of a DHTML/Ajax app from a Rev app - after all, what he's suggesting is basically something similar to GWT or Morfix (in fact, maybe it is closer to Morfix). The real issue (I think) is how to make Rev performant on the web side of things. This goes back to the usage of FastCGI in place of regular CGI (I'm just going off what I've read on the list - I have zero experience with Rev as a CGI tool).

It seems to me that this is the issue that must be really addressed.

Theoretically it doesn't seem to be that difficult. The crux of the matter is that the engine that is serving a particular user needs to retain the state of that user's actions and data. As far as I can see, what is needed is some kind of dispatcher that would stand in front of multiple instances of a Rev CGI (the instances could even be on different machines, and the dispatcher would record the IP address of each instance when it regisitered with the dispatcher). Each user would need a session key that would identify the instance and the variable space on that instance for that user's state. The variable space could just be a new stack that was identified by some unique ID (e.g the millisecs and the user's ip address), or if that was too slow then a custom property set. After a certain period of inactivity the user's session data in the variable space would be deleted.

If this problem on the server side is not solved, then I think the rest of this project will always face a bottleneck that will limit the number of people who can use these Rev-generated Rev-RPC calling apps. If there is a bottleneck on the server-side, then no matter how easy it is to generate Ajax apps from Rev, those apps are going to behave unpredictably when making their calls to the server.

Just my 2 cents. As I say, I could be talking rubbish, as I've never used Rev CGIs.

I'm going in almost totally the opposite direction to Andre - I'm using Rev as a "net-savvy" app that is talking to Java back ends. That way I get the highly flexible, GUI-rich, cross-platform benefits of a Rev application, with the heavy lifting being done by the huge resources that large enterprises have poured into server-side Java, and the enormous number of hours of free programming done by open source developers, and a wide array of RDBMS options all available through JDBC. The trick here is choosing wisely among all the available Java web frameworks to select one to find the most effective way to use Java without getting bogged down in something very complex and that requires huge amounts of developer time.

Of course the problem doing things the way I am, is in getting people to download the application. For my target market, that is not going to be a problem. In fact, if an application was compelling enough, I don't think that would be a problem with the majority of users.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: Rev and Java

Post by marielle » Tue Dec 05, 2006 1:56 pm

Bernard wrote:Just my 2 cents.
That feedback is worth a lot more than 2 cents. Many thanks for these information.
Bernard wrote:I'm going in almost totally the opposite direction to Andre - I'm using Rev as a "net-savvy" app that is talking to Java back ends. That way I get the highly flexible, GUI-rich, cross-platform benefits of a Rev application, with the heavy lifting being done by the huge resources that large enterprises have poured into server-side Java, and the enormous number of hours of free programming done by open source developers, and a wide array of RDBMS options all available through JDBC. The trick here is choosing wisely among all the available Java web frameworks to select one to find the most effective way to use Java without getting bogged down in something very complex and that requires huge amounts of developer time.
Yes, that's the direction a few of us are taking. If you have specific projects based on this type of solution, is it possible to know more about these?
Last edited by marielle on Tue Dec 05, 2006 2:47 pm, edited 1 time in total.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: Rev and Java

Post by marielle » Tue Dec 05, 2006 2:17 pm

Bernard wrote:The crux of the matter is that the engine that is serving a particular user needs to retain the state of that user's actions and data. As far as I can see, what is needed is some kind of dispatcher that would stand in front of multiple instances of a Rev CGI (the instances could even be on different machines, and the dispatcher would record the IP address of each instance when it regisitered with the dispatcher). ...
This got me think of insead by Pierre Sahores. The tag line is "From CGI scripting to real TCP/IP applications servers in using the RunTime Revolution environnement under Linux, Mac OS X or Windows XP"

I got from a google search that somebody already told you about this ;-). My understanding is that insead doesn't do all or the above (or does it?).

The text in the introductory documents I have in local copy is :
Because the solutions described below rely on the httpd deamon (Apache 1.3.x or 2.x.x, IIS 5.x) and the PHP Apache module (3.x.x or more recent).
This suggests that this simply relies on a standard Apache server for the tasks you described (but my understanding of such topics is rather weak, feel free to correct me).

Insead was supposed to be at this url but the page doesn't work anymore. No link to this I could find on Pierre's webpage.

Did you have a chance to look it up? If yes, what is your opinion?
Last edited by marielle on Tue Dec 05, 2006 2:48 pm, edited 3 times in total.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: Rev and Java

Post by marielle » Tue Dec 05, 2006 2:30 pm

Bernard wrote:I suggested before that Ajax/Flash targets were a possibility for delivering applications built in Rev. In the current thread I was just quoting an excerpt from an old post of mine last year. I'm hoping that there could be wider discussion of these issues since Runrev have recently voiced an interest in seeing what people want in terms of interfacing with browsers.
In a use-revolution post

Yes, I have the same hopes.

I had a look at Morfik a while ago. If you are any interested, I will take the time to sort my notes and pointers on such topics (templating solutions in this context)... but I don't have the time for this in the following days. Simply remind me if you see nothing here in a week time.

Keep it going. I hope others will take advantage of the fact I am busy to join as well.

Bernard
Posts: 184
Joined: Sat Apr 08, 2006 10:14 pm
Location: London, England

Post by Bernard » Tue Dec 05, 2006 3:09 pm

That feedback is worth a lot more than 2 cents. Many thanks for these information.
That's kind of you to say so - but I'll stick with the original 2 cent estimation ;-)

I regret to say I don't share others interests in Morfik. I first heard about Morfik about a year ago. I do not think that it is RAD enough for me.

Indeed I am aware of Pierre's work for INSEAD. I've discussed it with him on the Rev/Metcard forum 3 or 4 years ago. I think it is very ingenious and shows his preparedness to think outside the box. His solution is very simple (despite what others might think), and if I remember rightly was actually devised by him in discussion with Scott Raney before RunRev acquired the engine. Whilst I'm sure Pierre's solution is very performant (and gets over the blocking issues involved in Rev CGIs), to me it is very important to have the kinds of enterprise connectivity provided by JDBC, provided that the use of the Java layer does not significantly impact application performance. In my situation the Java layer does not add much complexity, and does not have any significant effect on the application's performance. After using J2EE for a couple of years back around 2002, I've eschewed J2EE and only used J2SE. I know that Pierre has endorsed the idea that RunRev support JDBC, but to be honest I'm not sure what that would involve.

Without going into the details of what I'm doing, I'm simply making use of Rev where it is at its strongest - creating networked, stateful, scriptable GUI applications. My applications just read back data (some in XML, some just in tab-delimited format) from the server, and modify the Rev front end on the fly. I could swap out the front end for Flex or Laszlo. But I can't see much benefit in my situation, as I would need to learn GUI development in those tools. When I did look at Laszlo last year the compile cycle was so ludicrously slow on my top of the range Powerbook, I knew that Laszlo was a non starter for me unless things changed. I haven't revisited Laszlo yet to see if that situation still exists.

As things stand I don't think there is a better cross-platform, scriptable GUI tool than Rev. But on the server side, a multitude of people far cleverer than me have spent years honing servers and tools and frameworks. For me, it is better to take advantage of the work they have put in doing these things.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Post by marielle » Wed Dec 06, 2006 4:11 pm

Bernard wrote:Without going into the details of what I'm doing, I'm simply making use of Rev where it is at its strongest - creating networked, stateful, scriptable GUI applications.
I am 100% with you on this one.
Bernard wrote:My applications just read back data (some in XML, some just in tab-delimited format) from the server, and modify the Rev front end on the fly.
Even outside of any network connection, this type of solution is very powerful.
Bernard wrote:When I did look at Laszlo
Yes, tried Laszlo, tried XUL, evaluated many things. Event got a look at this XPCOM which is another one of these talked about things.
Bernard wrote:As things stand I don't think there is a better cross-platform, scriptable GUI tool than Rev.
I have a similar evaluation.
Bernard wrote:But on the server side, a multitude of people far cleverer than me have spent years honing servers and tools and frameworks. For me, it is better to take advantage of the work they have put in doing these things.
That looks like a very sensible approach to have ;-)

Death
Posts: 15
Joined: Thu Oct 19, 2006 5:56 pm

Re: Rev and the Web, feedback wanted.

Post by Death » Sat Dec 09, 2006 7:18 am

Jeez! When you're right you ARE right!
Couldn't agree more!

As I said earlier: it is all out there, REV should concentrate on becoming stable and feature rich; then let's worry about doing that which others already do very well...

And with the browser integration and URL commands, one can already script in JS etc, or export custom flash code to run in it etc. etc.

I won't repeat you here Marielle, you put it so nicely already...

And for those who might want to make this personal, nobody attacked anybody here... Marielle just stated a few known and utterly correct facts to consider in her argument.

However, it seems to me that everybody always wants the stuff the don't want to learn integrated into the stuff they know how to use...

If REV went for this, they would have to integrate every known technology/language out there to satisfy those IMO

And as far as I am concerned, Java can go to where the sun doesn't shine, it is yesterdays attempt of portability gone horribly wrong... (Just my op., let's not make this a flame war about Java)

Bernard
Posts: 184
Joined: Sat Apr 08, 2006 10:14 pm
Location: London, England

Post by Bernard » Sat Dec 09, 2006 12:13 pm

Marielle, thanks for the reference to the Jamaica JVM. I followed the links to Judoscript, and in my circumstances it looks very interesting.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: Rev and the Web, feedback wanted.

Post by marielle » Sat Dec 09, 2006 3:03 pm

Death wrote:And with the browser integration and URL commands, one can already script in JS etc, or export custom flash code to run in it etc. etc.
Note that I didn't really express a criticism against the idea of exporting to the browser (neither did you, I believe).

It's just that I don't really see the contribution of having to create a fully fledge framework that would be able to export about any content that you could have in a xtalk stack into a browser (which I understand to be a point you make as well).

If you read any book about business, one notion that is introduced early is the one of market vs product. A product is what is being bought... by a given market.
"A market consists of a group of current and/or potential customers having the willingness and ability to buy products – goods or services – to satisfy a particular class of wants or needs. Thus, markets consist of buyers – people or organizations and their needs – not products. [...] Markets consist of buyers not products ’’
(Source: The Business Road Test).

The market of persons who want to write very complex applications on the web seems to be already well served.

That doesn't mean that I believe that it doesn't make any sense to provide export facilities. Look at the above. "Satisfy a particular class of wants or needs".

I believe that when it comes to consider export to the web it makes more sense to adopt a type of templating approach or automatic generation of interface based on predefined standards approach based organization by which you would allow the customer to edit some material in a stack, with the option to save data locally and let him present these data within a browser.

That's the reason why I linked to that Exercist project of mine, which takes that approach. Export data edited within a revolution stack into some standard format (xml, json, etc.) and use these data to fill in some predefined templates. Sometimes, the templating system can be quite complex. I have for instance designed a fairly generic learning activity generator that works both in xtalk and in javascript as they generate a visual interface starting from the same xml specification.

I believe in this kind of approach. It makes it possible to have at quite low cost (in terms of development time and complexity) applications with a desktop side and the web-side of things tightly integrated... for products that serve well-defined markets.

There was no attack at all in my invitation to write requirements first. This is a very serious recommendation. It is important to avoid to write too generic a framework and to rather write the specs for a product that might sell. As an example specs that can be written to meet the specific needs of a specific market, feel free to check out the specs part or the manual for the exercist project. (There are also demos but I have been told they don't work well on some version of IE -- sometimes they don't work at all in a IE browser).

And the reason I reacted on the fact that Dan was inviting persons to contact him privately is that once you take this type of approach, competition between developers is importantly reduced. Once you set yourself to serve a niche, then you rapidly discover that there is a huge number of niches to serve out there. In fact, it would rather be beneficial to have the persons interested in this kind of approach to freely discuss and freely share the code that is common to these different approaches.

--------------------------------------------------------------------------------

If you really want to go for something "generic", then an interesting candidate is Zimbra or of more interest, Zimlets

"Zimlets are a mechanism for integrating the Zimbra Collaboration Suite (ZCS) with third party information systems and content as well as creating "mash-up" user interfaces within the Zimbra suite itself."

Not having spent too much time evaluating that technology it seems possible to consider an export mechanism within revolution to get things in zimlet format (again, as a specialized plugin, not a chore revolution module)

White Paper
gallery

The big advantage of zimlets (over xul or other Laszlo) is that rather than propose you some generic framework that can do about anything you could think of, it rather let you reuse components that do a specific task.

--------------------------------------------------------------------------------

Another approach that is worth checking out is CakePHP

Cake is a rapid development framework for PHP which uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. Our primary goal is to provide a structured framework that enables PHP users at all levels to rapidly develop robust web applications, without any loss to flexibility.

--------------------------------------------------------------------------------

And if are not convinced yet that the web market is well served with widget solutions better than we have the time to design within our small community:

Active Widgets, behaviour, dojo, jquery, jsan (somehow), magnolia,miraculous, mochikit, pajaj, prototype (with protowidget based on it), qcodo, qooxdoo, rialto application server, rico, sajax, scriptaculous, swato engine (java), symfony (php), tacos, textile, vitamin, xajax, xoad (php), yui, zapatec, Zephyr.

Even more at PHP Ajax Frameworks

--------------------------------------------------------------------------------

No, this list is *really* not to encourage xtalk developers to evaluate these different technologies. The reason I posted a rather short list of solutions available out there is to send the following message. Frameworks are exploding like mushrooms out there. Things are changing, very rapidly changing. Some frameworks disappear, other emerge. Hopefully, most of it will consolidate within 3-5 years. But going for designing a system within xtalk that is too much dependent on any single one of these framework is a bit dangerous right now.

In contrast, if you develop a product with a specific market in mind, where an UI is automatically generated on the basis of specifications that you are the one to fully control, then there are far better chances of making it in the longer terms. My 2 cents.

--------------------------------------------------------------------------------

And if you need to produce web applications with liitle knowledge of javascript, then why not try ZK

ZK is an open-source, all Java, Ajax Web application framework that enables rich UI for Web applications with no JavaScript and little programming.

Now that ajax is gaining in popularity (if you checked out sitepoint last report on the state of web development, Ajax is expected to take over flash in 2007). Because of this, you can be sure that they are very many teams of highly competent engineers who already started designing RAD for javascript/ajax application *months* ago. Very good ones should be available within less than 1 year time. These applications will be better than what can be produced by a team of one or two persons in this community... even if these persons choose xtalk as development environment.

--------------------------------------------------------------------------------

My own view on where xtalk developers should be going: Don't try to design a general framework. Serve niches. Xtalk let you serve niche markets faster and better than any other tools out there.

--------------------------------------------------------------------------------

Then what is common to all the frameworks above. They try to isolate design patterns and propose implementations for design patterns.

That's the thing missing in our community.
A ‘pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice’ (Alexander, 1977). At a simple level patterns are a way of recording the knowledge of experienced practitioners, best practice and lessons learned. Patterns originated in the field of architecture but pattern use has since spread to include:
Concrete examples, in the context of interface design can be found on the on-line companion to the book "Designing Interfaces". Another example, the very famous Yahoo! User Interface Library. Another example, the recent book by O'Reilly Ajax Design Patterns.

And this goes back to what Death said. Let's solidify xTalk first.

Let's provide well thought solutions for well identified types of problems.

Once we have done that within revolution, to provide an export mechanism to any existing mechanism would be a lot easier. We won't need any complex framework or change anything to the engine to do it.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: Rev and the Web, feedback wanted.

Post by marielle » Sat Dec 09, 2006 3:25 pm

marielle wrote:Let's provide well thought solutions for well identified types of problems.
Guess what, I have set up a mechanism by which members of a community could collaboratively edit a library of patterns. The example I have to give is in another domain, learning activities, but the mechanism is the same (Learning Activity Pattern). It's making use of the very clever Content Construction Kit in Drupal.

Problem is, I cannot really take responsibility for this on top of other things I already do. If anybody wants to install that on their private website, I will gladly help them install Drupal and the appropriate modules on their server. If somebody is keen to take responsibility for this, I would be happy to install Drupal with the appropriate modules on my server. I already do that for persons who have now become friends, iberry-open courseware, Learning Chinese project -- The deal then is: I teach you how to fish... and once you have learned, you will make a bit of time to do the same for at least 2 other persons -- that's a concept called Pay it forward.

Something could be done even more easily if the patterns were edited from within an xtalk stack and published on-line, for instance on that revdeveloper wiki.

Well, I guess it will take a bit of lobbying to get there (and I haven't started it yet). We probably need to first pass the test of the Beta to get them trust us, developers, a bit more ;-).

Yes, I do believe in the notion of social responsibility. I do believe that we, as users, have the power to very positively influence the diversity and quality of resources within this community. There are very many things that can be done to improve our lot as users that don't require any change to the engine or any action on the part of revolution's staff.

This is in no way an attack against Andre... Andre if anything is providing a great example of paying forward. I hope that the fact that he decided to let the community benefit from a resource he generously made available within the community will encourage persons who make use of these resources for commercial projects of their own to give a bit forward to the community. (but I am sure that Andre's view on this is that if the solution is really critical to the success of a project of yours, a donation on Andre Paypal account should be considered as well ;-) ).

Nice circle... and yes, it is important with after having used Andre's post to discuss other aspects to come back to Andre's contribution.

That's a great contribution.

Has anybody already started thinking how they could use Andre's solution in their projects?

marielle
Livecode Opensource Backer
Livecode Opensource Backer

pay it forward

Post by marielle » Sat Dec 09, 2006 4:26 pm

What about this? Add to the creative commons license a "pay it forward" license. Similar to share alike except that you don't get to share any modification of the original work... you get to share two other resources of yours within the community that you release under a "pay it forward" license.

Nah. Probably a silly idea.

Post Reply

Return to “CGIs and the Server”