Rev and the Web, feedback wanted.

Are you using LiveCode to create server scripts or CGIs?

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

SoapDog
Posts: 84
Joined: Sun Apr 09, 2006 10:03 pm
Location: Niterói, RJ
Contact:

Rev and the Web, feedback wanted.

Post by SoapDog » Tue Nov 28, 2006 6:06 am

Boa noite, Friends,

I sent this first to the use-revolution list but I think it was reject for being a big email.

Again on this list we touch the topics of browser plugins, flash export and other possible web related features. People from the RunRev team came forward and asked us for feedback and requests and many answered to this call. This email will be my thoughts on the topic of web and rev, it will be a very long email and I'll touch many topics but in the end this will remain an opinion piece and others may have a different point of view. I hereby apologise for my lack of english grammar skills and my typos, even before they occur. English is my third language, portuguese is my first, cursing my second and english my third. I'll first talk about flash, web browser plugin, java bytecodes, I'll be against them all, then I'll talk about what I think is the future and that it can be done now if people help.

It's been mentioned before that Revolution should export it's stacks to flash, I don't think this is feasible not only by a technical standpoint but also for a theoretical point of view. Flash is a multimedia presentation authoring tool. Runtime Revolution is a turing complete application building language and IDE. Revolution has features such as database access, tcp and udp networking, native GUI support which don't map well to Flash. I am not even touching topics such as the unique nature of stacks, cards, objects, customprops and the message path. I don't think the feature set and the mind set behind those two apps map well to each other, so therefore, I recommend against such solutions but the SWF format is open and anyone is encouraged to try some experiments.

Other possible solution was the creation of a web browser plugin, this is certainly more attractive to me than flash and more feasible. The idea of a plugin although is very hard because not only RunRev team would have to support lots of platforms (at least linux, windows and mac os x) but also each browser for each platform (safari, mozilla, explorer, opera), the amount of resources to create such thing would be enormous. Also what is the real difference between downloading the Revolution Player and having a browser plugin? Both will be about the same size but the plugin will be confined to the browser canvas (okay, it might be able to spawn its own windows too) and the Revolution Player one will be running on the "real thing". As far as my experience goes with Revolution Player, if any user needs to use my software, he will gladly download the player, he acknowledges no difference between downloading a player and a plugin. The player is less work for RunRev as a windows player will work in every windows, a browser plugin will depend on the browser version. So I'd rather use the Revolution player than a plugin.

The idea of making the engine generate java bytecodes is very entertaining because this would enable us to use revolution to build servlets for our web server end, midlets for our cellphone or pda programming and applets for those that really want to be confined to a browser canvas. I don't know much about java bytecodes although I put a book specially about generating java bytecodes from languages that are not java in my Safari bookshelf. The idea is very nice except for the fact that the WHOLE RUNTIME REVOLUTION ENGINE WOULD NEED TO BE REWRITTEN, sorry for the all caps, but we needed emphasys. To create such bytecode thing, a new engine would need to be built, we would not be able to re-use none of the C/C++ code. A new engine from the scratch. We don't have the resources for that either, writting a new engine?! Just pick everything scott raney did, all the things runrev added during the last years, throw it all away and build it again just for using java bytecodes. I don't think we can do that now.

Okay, my rant is finished, let us talk about new things, about Revolution and the Web in the way I see it.

First, let me begin by my all-wise-axiom

People don't want Rev to run on the web, they want the development experience of xTalk and to be able to deploy for the web.


Explaining, no one really want Rev on the web. Having a Revolution built application on an end user machine or a <favorite language> built application on the same machine, is the same thing for the user. The difference is on the side of the developers. We like xTalks because of the stacks, cards, properties, english like language, way of interacting without compiling and this kind of stuff. We wish that developing a web application would be as easy as that. If we had a little xTalk environment that would allow us to visually create our web gui and use a xTalk language to code the server side without the need to compile, upload, debug just to do our testings, I bet people would be very happy.

People keep asking for flash export, web plugins and java bytecodes, not because they think those technologies are a superior thing that RunRev should incorporate but because they can't stand developing using Adobe Flash MX, Visual C/C++ and NetBeans. We're often looking by the wrong side of the problem here on this list. No one wants flash support because they think actionscript is superior to transcript. They want flash support in rev because doing all the work on flash mx sucks. People here realized that XHTML + XSLT + PHP is as simple as the holy roman empire was holy, roman and an empire.... we want the easiness of Runtime Revolution with it's marvelous and unmatched development experience and we want it because as we realized this is the right way to do things, we can't go back to the PHP... (some people can but belive, if the could do it in transcript, they would).

Now that I've stablished the problem, let me talk about the solution I think. This is not coming out of my mind all of a sudden, I've spent the best part of the last three years thinking about it and talking with very wise people here, so I expect the readers will at least give me the benefit of doubt and read till the end. I also want feedback on this ideas because they may become something I'd devote much of my free time.

The problem of converting from Revolution to the Web is that again, those two things don't match, it's comparing oranges to shoes (Jacque, this quote is to make you happy). Web is a stateless technology to display hypertext, we're taking it to the limits by using CSS + XHTML to create rich user interfaces, javascript to give it half a brain and xmlhttprequest object to fake state in it. Revolution applications have a rich user interface out of the box, a whole brain and knows it states. If we try to convert from Runtime Revolution to the web we will stumble in many blocks such as:
  • web is client/server, normal stack applications are monolitic. How to split stack code in client/server way? should all go in the server and be executed as CGI, to make this as transparent as possible, all calls to code would be done using xmlhttprequest object (AJAX techniques) and this would make a lot of server roundtrips and waste a lot of bandwitdh and server CPU cycles or should we convert some parts of it to Javascript and run it on the browser and allow just some logic on the server, this again poses a problem because I can't think of any fail-proof way to code a tool to do that decision without human intervention.
  • Revolution is rooted into the stacks, cards, objects paradigm. The most used control is probably the button and the second is probably the field. The web is rooted into HTML which seldon uses buttons or text fields (in the text entry style). To map from a runrev stack to the web, the converter should be wise enough to deal with that problem.
  • The message path can be faked but some things cannot. Send in time can't be used. There's no persistence, as soon as the cgi returns, it life ends, there's no more cycles to use (unless you're using javascript in a loop in the browser or fastcgi in the server) so things like send in time or reacting to an event, can't really happen. No way a code in the server will receive a mouse enter event unless this thing is trapped by javascript, encoded somehow and send using a HTTP request to the server.
This are just some roadblocks on the conversion from revolution to the web, there are many more such as the engine being single threaded (which is a non-issue if you're using cgi but a big issue if you're using fastcgi). If you want to have a simple glimpse of the nightmare this conversion is just think how the following line should behave on the web:

Code: Select all

go stack "another stack" with visual effect push left
Will this use a 302 redirect? a meta refresh tag? the effect will be done with CSS and DOM manipulation? what if there's no javascript in the host browser?

Converting from Runtime Revolution to the Web will prove to be an herculean task if anyone expect all kinds of stack to run. I don't think such approach will ever work right and I have indeed another solution to market. I'll use another axiom.


There are more helicopters in the bottom of the sea than submarines in the sky.


Converting from Revolution to the web is the same thing as put a submarine in the sky. We should aim to put the helicopter in the sea, it's far easier, actually it happens all the time. Let us look at our problem backwards. Okay we can't convert from Rev to the web, but what if we can convert from the web to rev?

What we want? We want the marvelous development experience of xTalk and to be able to deploy that on the web. How we will achieve that? By mapping the web back to Rev.

Whats the root thing on the web? The page. How to map page to rev, by using cards, each page is then a card.

What encloses a web application? a collection of pages and it's supporting server side code. How to map that to rev, by using stacks, each stack a single application package or component.

We know that our tools pallete doesn't match the usual web controls, so we need a new pallete with "web-savvy tools" this tools could be a simple modal plugin with new tools such as TEXT, IMAGE, CONTAINER, and this tools could be easily converted to the usual HTML + CSS. For example HTML uses nested nodes such as /html/body/div/p for a paragraph that belongs to a div. How is that different from Rev groups, if you group all your card controls in a parent groups and had a nice "web inspector" to give it a type "div" we could simply map the tree nature of HTML back to Rev by using nested the groups. So all we need is a new tools pallete able to create objects that can be easily converted to their web counterparts and a new inspector that should have features to aid this conversion such as "positioning tools", most of the CSS will use relative based position while rev uses absolute coordinates, a new inspector to deal with that kind of stuff.

Take notice that what we're doing is not think how to map revolution to the web but the other way around, how to pick the most common web stuff and map back to rev so that after we do this mapping, we can simply write our web-tools.

Web applications usually have a server side component that that deals with core business logic that is not possible to be dealt by using javascript on the client side. We can map that to stack script and make the stack script a cgi/fastgi whatever. If we write a nice RPC system we can make the stack script hold the server logic and export it as methods to be used by the client side which is CSS+HTML+Javascript+A Human.

To illustrate my ideas, imagine a simple money conversion. In the web it would be two fields and two popups and one button. the two fields would hold the amounts, the two popups the currency types and the button would convert from one to the other. The client side would use AJAX techniques to make the life of the user easier, so simply clicking the button would do a roundtrip to the server, convert the amount and then using javascript + DOM manipulation it would insert the answer in the text field. How would that map to Rev. The fields and the popups and the button all have an equivalent on the Rev standard tool pallete, we would need a new web-savvy inspector to accomodate the needs of positioning and ids/class stuff for xhtml. The server component might just be the convert function on the stack script. Okay we have our maps. How the magic conversion occurs then? We need a new "web distribution builder" tool that would scan and process a stack converting it all to HTML + CSS + Javascript + CGI. This tool would pick the stack script and pack it as a CGI and expose it's functions thru some RPC mechanism, it would convert the card layout to a web page format using the web-savvy properties created by our own web-savvy inspector to guide it when needed. It would convert the control scripts to javascript and relay each call to a method that is inside the stack script to a RPC call to the server component, for this to be feasible the script on the controls should be as small and direct as possible, maybe just variable bindings and the call to the stack, nothing more would be allowed, let me illustrate such control script conversion.

Transcript button example:

Code: Select all

on mouseup
  put field "amount" into tAmount
  put field "currency type" into tCurrencyType
  put convertCurrency(tAmount, tCurrencyType) into field "result"
end mouseup
web-thing conversion
The button would be something like this

Code: Select all

<input type="button" onmouseup="javascript:buttonMouseup()" />
meaning the html button has a javascript methond connected to it's mouseup event. then we have a almost line by line conversion.

Code: Select all

buttonMouseUp() {
var tAmount  = document.getElementById("amount");
var tCurrencyType  = document.getElementById("currency type");
document.getElementById("amount").innerHTML = RPCCall("convertCurrency", tAmount, tCurrencyType);
}
See, if the conversion is just variable binding and method calls, it's pretty straigth forward, just need to create some RPC mechanism, it might be XML-RPC, SOAP, REST or something new. Let me make a resumé.

We need a new tools pallete that is able to drag and drop web-mapable objects.
We need a new inspector that is able to deal with the features we expect from a web object such as relative position.
We need a new distribution builder that is able to pick that stack and convert it to HTML & Friends + CGI.


You will ask, but I still need to upload everything to test and that spoils my pure xTalk development experience and I will answer: no you need not. We have RevHTTP transcript based web server that can run inside the IDE, a simple IDE plugin running the server will allow you the standard xTalk experience, develop live on the IDE, switch to the browser, load the page from inside RevHTTP that's live on the IDE, full xTalk experience, no compilation needed.

Everything I said can be built now, it doesn't even need to be built by the RunRev team, it all can be built in pure transcript just by adding plugins to the IDE. It can be done now, all it needs is leadership and a team of developers. Thats what I think that needs to be done. That's how I envision developing for the web using Runtime Revolution, I don't know if I was clear and I really want to talk about this thing to make everyone understand what I am trying to talk about.

It's now 2:53 AM... I think this email to too big for the mailserver to allow me thru. I'll try anyway.

Andre
http://www.andregarzia.com

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

Post by Death » Tue Nov 28, 2006 9:52 am

I think making Rev something like Flash etc is a mistake, it's already out there (Flash for ex.) hehe

The people who want Flash, already bought it...

Also downloading the engine once is no big deal, and then any stack will run anyway.

So I don't get the problem...

This problem is in every group that I know:
Some guy finds a proggy (like Rev) which he likes, now he wants it to be "something else" also, 'cause he's too lazy to get into the other languages that already do that "something else".
Or, they want the new proggy to be like the old proggy that they know, but it doesn't do what they want it to do, so they bought the new proggy
...
Then the griping starts: "Why isn't it like my old proggy? like VB?, Why isn't Flash? why...why

You get the idea...

Inet and WEB support are of course very important, but not as an emulator for Java, Javascript etc. These languages are already out there, use them instead.

I think the most important parts are:
Bug fixes, optimization, more graphics "tricks", DB support (as in RAD tool), animation support, printing/reporting support, more standard and nonstandard controls.

If I want to do WEB stuff, I use RAD's like Frontpage and JS, PHP etc, they were made for this and I don't think REV should be sidetracking into competing with a gazillion WEB tools out there...

Good night...

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: Rev and the Web, feedback wanted.

Post by marielle » Tue Nov 28, 2006 11:55 am

SoapDog wrote:

Code: Select all

<input type="button" onmouseup="javascript:buttonMouseup()" />
meaning the html button has a javascript methond connected to it's mouseup event. then we have a almost line by line conversion.

Code: Select all

[/quote]

Have you heard of [url=http://www.creysoft.com/jscard/]jsCard[/url]? That's an xTalk to JavaScript language translator.

It's seems that they are already well advanced in that direction. 

[url=http://www.creysoft.com/jscard/firefoxonly.html]Check up their demo[/url] (firefox only)

revdan
Posts: 21
Joined: Sat Apr 08, 2006 5:59 am

I think Death misses part of the point

Post by revdan » Wed Nov 29, 2006 7:12 am

Death wrote:I think making Rev something like Flash etc is a mistake, it's already out there (Flash for ex.) hehe

If I want to do WEB stuff, I use RAD's like Frontpage and JS, PHP etc, they were made for this and I don't think REV should be sidetracking into competing with a gazillion WEB tools out there...
Death (shudder), I think you miss at least part of the point Andre is making here. If we were just talking about doing Web pages and converting xTalk to JavaScript, I'd be somewhat inclined to agree with you (though I'd still pine for the ability to use Rev as my scripting language). But the important difference here is that we're talking about building Web applications, not Web pages. The server-side component, which Andre suggests be embodied in the stack script, is one of the things that sets this approach apart. I can use Rev for both ends of the application and deploy on the Web. That feels to me like a big win if it can be pulled off.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: I think Death misses part of the point

Post by marielle » Wed Nov 29, 2006 10:37 am

About this part:
revdan wrote: The server-side component, which Andre suggests be embodied in the stack script, is one of the things that sets this approach apart.
I would agree with Dan. This part of Andre's work would be a major addition to Revolution.

About this part:
revdan wrote: I can use Rev for both ends of the application and deploy on the Web. That feels to me like a big win if it can be pulled off.
I would agree with Death.
Death wrote:I think making Rev something like Flash etc is a mistake, it's already out there (Flash for ex.) hehe
As rule best is not to spend too much efforts repeating what exists and to rather work on making revolution very good at what other software are not that good at. Rapidity and relatively low complexity of development on the desktop.

If solid technologies exist, there is no point reproducing them. You don't really need to use revolution as an editor for web objects. This could be a *very* nice piece of software. Some ability to translate revolution content into alternative format (serialization into a xul format or a xtalk to javascript conversion) would be very useful as well. But both are in my view to be treated as specialist extension or a specialized piece of software, not necessarily something that is seen as part of the default distribution of revolution. It could be integrated when it becomes robust enough... but best would be to treat it as a separate plugin early on.

Given that altuit browsers will soon be part of revolution, what is also of interest is to find a way for revolution to speak to javascript or to interact with javascript objects. (Sure, I have heard of js being a browser-side technology).

To be able to run a webserver locally, without any need for the user to have access to his own computer as localhost would also fall into that category... have Revolution let you easily do what other software don't allow you to do easily (note that I haven't had time to carefully read the full post yet).

Andre, are you aware that you could develop this kind of plugin/extension to revolution yourself and make an income out of it? Why not contact Revolution's marketing department (Lynn Fredricks, I believe) to enquire about this?
Last edited by marielle on Wed Nov 29, 2006 11:00 am, edited 2 times in total.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: Rev and the Web, feedback wanted.

Post by marielle » Wed Nov 29, 2006 10:54 am

SoapDog wrote:How the magic conversion occurs then? We need a new "web distribution builder" tool that would scan and process a stack converting it all to HTML + CSS + Javascript + CGI. This tool would pick the stack script and pack it as a CGI and expose it's functions thru some RPC mechanism, it would convert the card layout to a web page format using the web-savvy properties created by our own web-savvy inspector to guide it when needed. It would convert the control scripts to javascript and relay each call to a method that is inside the stack script to a RPC call to the server component, for this to be feasible the script on the controls should be as small and direct as possible, maybe just variable bindings and the call to the stack, nothing more would be allowed, let me illustrate such control script conversion.
My understanding is that this solution, Ajax Pages would allow you to implement some kind of equivalent to a php solution without any server-side technology. It may provide a way to intreact with web objects as suggested in the post above. All you need then is a web-browser field on your card (revolution stack) with content defined by a html+css+javascript set of files, with each of these files that can be dynamically edited from within your revolution application.

SoapDog
Posts: 84
Joined: Sun Apr 09, 2006 10:03 pm
Location: Niterói, RJ
Contact:

update...

Post by SoapDog » Mon Dec 04, 2006 12:41 am

Marielle,

I don't want to make money right now, I want to have a wonderful toolkit that I will then use to make money. By making this work free and receiving patches from all round the xTalk community, we'll have a better toolkit than if I was alone building it and receiving money from closed source.

if anyone wants to donate money, my paypal account is always low :D

I am writting some better draft that I'll outline better this ideas, some people misunderstood me, probably by my bad english. As of jsCard, this is not where I am heading, jsCard is pretty cool but is running hypecard environment inside the browser, what I want is just to use the rev IDE and some additions to make self contained web applications, it sounds similar but it is not. :D

thanks for your replies.
andre
http://www.andregarzia.com

revdan
Posts: 21
Joined: Sat Apr 08, 2006 5:59 am

What I'm Interested In

Post by revdan » Mon Dec 04, 2006 1:09 am

Andre,

The part of this that I'm most interested in helping to develop is a drag-and-drop application that would allow the creation of the user interface portion of an AJAX app. I'm working now on examining the two or three most popular JS libraries to either pick one or define a common subset of functions to be made available in the tool. Then the idea is to allow you to lay out pages in an app written in Rev, try them out, and then generate the JavaScript and HTML to create those pages, which you can then upload to a server (probably semi-automagically).

If anyone else is interested in this aspect of the project, feel free to let me know.

Dan Shafer

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: What I'm Interested In

Post by marielle » Mon Dec 04, 2006 2:04 am

revdan wrote:The part of this that I'm most interested in helping to develop is a drag-and-drop application
This is *very* vague. Do you have any specs?

To start with, jsCard exists (an xtalk to javascript translator), so how does it differ from what you have in mind?
revdan wrote:AJAX app
If your ideas are about creating dynamic applications, this has in fact not that much to do with Ajax. Javascript in fact does most of the work for dynamically changing the css values. Usually you use Ajax only when you need to refresh some portion of the page content with data that are obtained via a cgi script or a mySQL database.

With jQuery (possibly one of the libraries you evaluate), for instance, you can write something of the like:

Code: Select all

  function products_hideAll() {
   $("div.boxProduct").css({display: "none"});
   $("ul.menu").find("li").removeClass("selected")
 }
 function products_showOnline() {
   products_hideAll();
   $("div.boxOnline").css({display: "block" });
   $("li#linkOnline").addClass("selected")
 }

This implies that this is the only difficult part of the project... create a system within revolution that allows to attribute behaviors to the objects in your interface. This is not very complex, it is just that it needs to be done first. You also need to take a widget approach. Again not very complex. It's just it needs to be done first.
revdan wrote:define a common subset of functions
What is to be done is not define a common subset of functions (if you take the two most popular ones, jQuery and Prototype, this is not possible because they rely on different syntax and they are not fully interoperable (conflicts -- though I believe jQuery has been working on this recently). What is to be done is to define a common subset of "behaviors" (stuff like "selectable", "draggable", etc.).

A good starting point is this "interface" library for jQuery.

On this:
revdan wrote:Then the idea is to allow you to lay out pages in an app written in Rev, try them out, and then generate the JavaScript and HTML to create those pages, which you can then upload to a server (probably semi-automagically).
There is really nothing very complex about this. This type of solution is already implemented in this activity editor, or the HTMLexporter stack in the stack gallery

Many things still need to be defined to get something close from specs. I would *by far* prefer to see interested persons discuss this on the forum. I believe there are around persons who have good knowledge of javascript (better than mine) and it would be a pity to keep any discussion private at this stage. [Paragraph rewritten as it was perceived as too offensive - Apologizes for that. The first version was written at midnight when my husband was pressing me to go to bed.]
Last edited by marielle on Tue Dec 05, 2006 12:16 am, edited 4 times in total.

revdan
Posts: 21
Joined: Sat Apr 08, 2006 5:59 am

It's Deliberately Vague, Marielle

Post by revdan » Mon Dec 04, 2006 2:20 am

Geez, Marielle, why must you always jump to attack and confrontation when a subject like this comes up?

As a careful reading of my post will reveal, I did not propose a fully specified solution. I indicated, rather, that I am in the beginning stages of exploring this possibility. I have no clue at this point whether it's feasible or whether the resulting product would be useful or even interesting. I'm just exploring out loud here.

I find it interesting that you cite two products that are not at all in widespread use or field-proven yet -- jsCard and jQuery. My research -- which extends over more than a year now, your view of my capabilities and understanding of the subject notwithstanding -- says there are a half-dozen widely used *user interface* libraries (which is my focus). Neither of these shows up on any list I've seen of important AJAX tools and technologies. Not to say they aren't interesting, but again, if you read my post, I said I was spending my initial time looking at widely used libraries.

You say, "If your ideas are about creating dynamic applications," when, once again, a careful reading of my post reveals I'm talking ONLY about the UI componentry. I think Andre's done a great job of looking at the code-based aspects of the problem and the application side of the AJAX equation. In fact, you point out the exact purpose of my product idea when you say, "Javascript in fact does most of the work for dynamically changing the css values." Precisely.

As for your personal attack on my "familiarity with the technical issues involved", I'll just let that one pass. I am comfortable and confident in my very deep understanding of those issues and I have enough working relationships with others on this list whose experience and views I also admire that such an attack neither threatens nor interests me.

By the way, I never suggested interested people contact me privately. That's your twist on the conversation. And this exchange is another great reason I have been all but invisible in this forum where I do not perceive a tone of civility and professionalism in many of the threads.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: It's Deliberately Vague, Marielle

Post by marielle » Mon Dec 04, 2006 11:47 am

revdan wrote:I find it interesting that you cite two products that are not at all in widespread use or field-proven yet -- jsCard and jQuery. My research -- which extends over more than a year now.
This is exact. jsCard is not a proven technology. It's only alpha. But it is doing *exactly* what you propose to do. So I am kinda of surprised that you don't consider it fit to be included in your research. Anyway, my question was "how is what you have in mind any different from jsCard". That's the part I am interested in... trying to better understand the problem that you are hoping to solve.

For what concerns jQuery, yes, this is still a bit new (appeared less than a year ago). However, jQuery is now directly integrated within Drupal, for the reason I gave "Allows different jQuery behaviors to be implemented on a site. Much like modules admn interface, allows you to (un)install jQuery behaviors. Each behavior is a set of jQuery plugin, with optional hooks implemented. Developers can contribute/fix behaviors by creating an Issue with component reference to "New Behavior/Behavior Issue". Code is still in early stages."

Despite its youth, it has already been used by solid webservices like Technorati.

What is unique about jQuery? The fact that it allows a plugin structure. No need for a huge library. You only integrate the add-ons you need in your current application. This is *really* powerful.... and also of particular interest for the type of application you described.

I am not saying that it is what you should be using. But I am saying that it seems to be something to evaluate if considering a project such as the one you described.

You say you have done a year of research. Why not share a bit of it on this list?

Anyway, as you are well aware, they are tons of technologies around. For too many to choose from. To guide any evaluation of the technology, it is quite important to start with writing requirements.... and then look for the technology you may need to meet these requirements, both in the very short term and with the longer term in mind (bet on a product that will still be around in 3-5 years).

In case this is any helpful to you, I posted some documents on writing requirements and use cases elsewhere in the forum.

If this helps, feel free to check out the rss feeds on javascript and web 2.0 technologies on my codes website
Last edited by marielle on Tue Dec 05, 2006 12:17 am, edited 15 times in total.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: It's Deliberately Vague, Marielle

Post by marielle » Mon Dec 04, 2006 12:20 pm

(removed)
Last edited by marielle on Wed Dec 06, 2006 3:59 pm, edited 3 times in total.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: update...

Post by marielle » Mon Dec 04, 2006 6:51 pm

SoapDog wrote:I don't want to make money right now, I want to have a wonderful toolkit that I will then use to make money. By making this work free and receiving patches from all round the xTalk community, we'll have a better toolkit than if I was alone building it and receiving money from closed source.
Apologizes for having been ambiguous. My comment on an opportunity for making money by designing a specialized add-on was only about the second part (an editor for web objects). For the first part, servlet functionality, I fully agree with the point you make.
SoapDog wrote:if anyone wants to donate money, my paypal account is always low :D
That would be a good investment to make for any user who relies on web technologies or consider doing so in the near future ;-)
SoapDog wrote:I am writting some better draft that I'll outline better this ideas, some people misunderstood me, probably by my bad english. As of jsCard, this is not where I am heading, jsCard is pretty cool but is running hypecard environment inside the browser, what I want is just to use the rev IDE and some additions to make self contained web applications, it sounds similar but it is not. :D
jsCard was a comment on this "<input type="button" onmouseup="javascript:buttonMouseup()" />"

Self-contained web applications would be *great*.

The part I don't understand well is how you see javascript to be essential to your solution. Is it that you are interested in some ability to play your stack in a browser (cf. you saying: 'We need a new "web distribution builder" tool that would scan and process a stack converting it all to HTML + CSS + Javascript + CGI')? Or is it rather that you require some template techniques, dynamic script alteration, assigning behaviours to web objects and changing these behaviours dynamically, in response to information obtained from a remote database, alike the ones found in javascript?
Last edited by marielle on Wed Dec 06, 2006 4:19 pm, edited 3 times in total.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: Rev and the Web, feedback wanted.

Post by marielle » Mon Dec 04, 2006 8:05 pm

SoapDog wrote:It's been mentioned before that Revolution should export it's stacks to flash, I don't think this is feasible not on
Oh, in fact, this may not be that difficult to get something basic using one of the open source technology below.

swfmill: swfmill is a command line XML to SWF to XML processor using SWFML, an XML dialect closely modeled after the SWF format.

jswiff: The aim of the JSwiff project is to create an open source, pure Java framework for Macromedia Flash file creation and manipulation.

jgenerator: The JGenerator is a web server production application that dynamically combines text, graphics, and sound to build rich Flash™ content. Similar to the Macromedia® Generator™ product, JGenerator uses the same data format and the same set of objects to perform the same tasks.

RSWF: RSWF is script written in Rebol language for making SWF files using own dialect language dialect (no XML or other stuff).

(Note that I haven't really tried any of them, so I cannot really tell if they really do the job. But this seems to be something worth exploring/evaluating).


And on the notion of "complete turing machine"... a literature I find quite interesting is the one on Meta-Programming System (MPS)

Language Orientated Programming (LOP): link 1, link 2, link 3, link 4

Source Code In a Database (SCID): link 1

Domain Specific Languages (DSL): link 2, framework for developing, link 3

Intentional Programming: link 1

Eclipse:link 1, see EMF

blah, blah: link 11
Last edited by marielle on Wed Dec 06, 2006 4:01 pm, edited 4 times in total.

marielle
Livecode Opensource Backer
Livecode Opensource Backer

Re: Rev and the Web, feedback wanted.

Post by marielle » Mon Dec 04, 2006 8:40 pm

SoapDog wrote:I don't know much about java bytecodes although I put a book specially about generating java bytecodes from languages that are not java in my Safari bookshelf. The idea is very nice except for the fact that the WHOLE RUNTIME REVOLUTION ENGINE WOULD NEED TO BE REWRITTEN, sorry for the all caps, but we needed emphasys. To create such bytecode thing, a new engine would need to be built, we would not be able to re-use none of the C/C++ code. A new engine from the scratch.
I don't know much about bytecode either (that I know nothing is probably closer to the truth). But I have in memory this claim: "Like Java, Rev's Transcript code is interpreted during development, tokenized into efficient bytecode. "
posted on REALbasic Network Users Group

It makes no doubt that Scott Raney was really no java afficionado Comments on "Sun's Java Compiler Falters" article? - 1996. But if the statement of the previous paragraph is true, then why should the engine be trashed in order to be able to tokenize the code into a java bytecode? Best bet for the ignorant person I am... because the engine does the conversation into some bytecode that is non java for now?

In article 36637FB4.7862E...@uswest.net, Scott Raney wrote:
> MetaCard is written in C++.

And java compilers have been written in C++. This GCJ - GNU Static Java Compiler seems to do something in that register. I know, this doesn't mean there is a straighforward transcript > java bytecode translation. However, projects like The Compiler Generator Coco/R or these various Language Parsers and Compilers may be relevant. To give an idea of this could translate to revolution, check out the formal description of the hypercard language. If not then maybe metaprogramming does offer some ways to think about the problem.

Well, as I said, I know about nothing about these topics. Please let me know of any absurdity I wrote.

For persons like me, who don't really know what bytecodes are Bytecode basics, Jamaica: The Java Virtual Machine (JVM) Macro Assembler

Post Reply

Return to “CGIs and the Server”