Re: Realbasic on the web without plugins
Richard, If it were only JavaScript, I'd say, SURE, I'll take that bet! But it's not. It's the ever-changing landscape of xHtml, HTML5, JavaScript, various DOM versions, and it's about the vagaries and hassles in trying to create actual working decent cross browser CSS. Its about learning Apache components, and understanding caching techniques, and how to connect to different databases, each requiring their own flavor of SQL or other language. And learning about schemas and relational databases, how to set them up, how to access and optimize them. It's about learning when and how to write stored procedures, and in what language. It's about deciding what framework is best, and what other client side AJAX APIs you need to learn. And most importantly, it's about the full time job of trying to keep up with all this technology and the HUGE and RAPID changes that are being made. There are individuals whose full time job is just keeping up with CSS. There are companies who ONLY purpose is to convert a Photoshop layout to HTML/CSS. That's the beauty of LC. You only have to learn a single IDE, and you CAN develop for all these other platforms. If I thought it was as simple as typing a few lines of JavaScript, then I'd be there. Sadly, it's not. But, look what RB is doing. They allow you to create a RB application which runs fine on your desktop, then wrap it in a binary exe and run it AS IS on a server as a CGI. And it returns a perfectly formatted HTML, JavaScript, CSS full-featured cross browser solution, without the dreaded plugin. And without the need for me to be on top of the latest CSS browser hack which makes something look right in iOS Safari. Now, I know RB is nowhere near as flexible as LC, Jerry tells me you can't even change the color of the the text on a button without having to write a C-plugin, and don't even think about rolling your own controls, BUT... If they can figure out how to take a subset of their functionality and build a full functioning web app, then surely it's in the realm of possibility for LC? Just sayin'. On Thursday, September 22, 2011, Richard Gaskin ambassa...@fourthworld.com wrote: Keith Clarke wrote: But even if it isn't easy, if RunRev don't grasp the nettle on this, developers who must deploy standards-based rich apps into cloud and locked-down Enterprise environments will be forced elsewhere, which would be a shame. I wrote about this last year: http://lists.runrev.com/pipermail/use-livecode/2011-June/157979.html Like too many of my posts that's a long one, but it represents pretty much everything I came up with that's relevant to the discussion, and I've been thinking about this a long time since two of my biggest projects are all about the web and are based in LiveCode. In short: There are two sides to this, client and server. On the server side RunRev has already provided what may be the most cost-effective solution for that with RevServer. But the client is a whole other game, fully immersed not only in a very different language but also in a deeply well-defined object model that, in many respects, bears little resemblance to LiveCode's. We use LiveCode because a good scripting language lets us build things more quickly than we could do in a lower-level language like C. But JavaScript is not a low-level language. It's almost as high-level as LiveCode, and as well integrated into the object model it supports as LiveCode is with its own. But the object models are very different. Attempting full translation of LiveCode to JavaScript would not be impossible, but very expensive. IMO, when you consider the limitations inherent in such a task, it's probably much more expensive than just learning JavaScript. That said, there are many opportunities for using LiveCode to generate some portions of the client-side experience for the web. A starting point was outlined here in 2006: http://lists.runrev.com/pipermail/use-livecode/2006-June/083956.html I haven't used the RB/web implementation, but I'd be surprised if it did full RB-JavaScript translation; my guess is that the server side is very much like RevServer and the client side is like the ToolBook approach I outlined in 2006. We can have that too, and we needn't wait for anything from RunRev - anyone with sufficient time and motivation can build this today. But somewhere along the way you'll eventually find limitations between what LiveCode can do on the desktop and what a translation to a different object model will be able to do on the web. There's more to apps than forms. And for those you'll want to use JavaScript. Fortunately, it's kinda fun to learn and there are orders of magnitude more resources for that than we have for all the things we've learned about LiveCode. Dive in, the water's fine. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Re: Realbasic on the web without plugins
Thanks for the response and reminder of your post, Richard. I read the 'first edition' but now understand more of the fundamental differences between LiveCode and web concepts (which I know slightly, but not much better)! ;-) I accept that there is far more to a web app than a set of forms, but then again, I don't see the need to map everything LiveCode to Javascript. Web apps tend to use MVC architectures or similar, so that developers can lock their intellectual property in the relative safety of the server. So, LiveCode Server would contain the main Model and Controller code and therefore most of the app wouldn't touch the client. The LiveCode language isn't currently designed to manage web pages. However, it's flexibility means that it could be easily extended with the necessary objects and functions (either in the core functionality or via a library or external). Page controller functions could manage those cards to be rendered as pages, adding template capabilities, DOM, layout management, markup for the contained UI elements and support for Ajax calls. See this Salesforce.com Visual Force Developer's guide to see how the Salesforce Apex language (analogous with LiveCode Server scripting) was exposed and extended for managing web pages http://www.salesforce.com/us/developer/docs/pages/index.htm IMHO LiveCode could be applied in a similar fashion to extend itself - indeed, this is the to do list! As I see it, with LiveCode Server in the back-end - with LiveCode page management functions in place - the only elements that would need to be mapped to HTML/CSS/Javascript would be the UI. And we have that to do list, too, as it's the elements currently banned from an LC Sever stack! So, if the LiveCode server stack contained cards (maybe in a designated 'pages' substack) that allowed UI components, the card UI controls could be associated with standard HTML blocks and CSS, with property mapping. Cards designated as pages could be complete 'LiveCode Pages' or divs to be rendered within pages of a web site managed outside of LiveCode. OK, there would need to be some Javascript glue for static pages, but the basics that could be a generic LiveCode Javascript or jQuery library. And of course, once this support for static pages was in place, the real challenge of recreating the rich app experience of LiveCode 'moving UI parts' could begin. However, meanwhile - and crucially - LiveCode developers could start delivering native LiveCode web apps into the Cloud and Enterprise space, where the browser plugin is generally not available. Best, Keith.. On 22 Sep 2011, at 15:39, Richard Gaskin wrote: Keith Clarke wrote: But even if it isn't easy, if RunRev don't grasp the nettle on this, developers who must deploy standards-based rich apps into cloud and locked-down Enterprise environments will be forced elsewhere, which would be a shame. I wrote about this last year: http://lists.runrev.com/pipermail/use-livecode/2011-June/157979.html Like too many of my posts that's a long one, but it represents pretty much everything I came up with that's relevant to the discussion, and I've been thinking about this a long time since two of my biggest projects are all about the web and are based in LiveCode. In short: There are two sides to this, client and server. On the server side RunRev has already provided what may be the most cost-effective solution for that with RevServer. But the client is a whole other game, fully immersed not only in a very different language but also in a deeply well-defined object model that, in many respects, bears little resemblance to LiveCode's. We use LiveCode because a good scripting language lets us build things more quickly than we could do in a lower-level language like C. But JavaScript is not a low-level language. It's almost as high-level as LiveCode, and as well integrated into the object model it supports as LiveCode is with its own. But the object models are very different. Attempting full translation of LiveCode to JavaScript would not be impossible, but very expensive. IMO, when you consider the limitations inherent in such a task, it's probably much more expensive than just learning JavaScript. That said, there are many opportunities for using LiveCode to generate some portions of the client-side experience for the web. A starting point was outlined here in 2006: http://lists.runrev.com/pipermail/use-livecode/2006-June/083956.html I haven't used the RB/web implementation, but I'd be surprised if it did full RB-JavaScript translation; my guess is that the server side is very much like RevServer and the client side is like the ToolBook approach I outlined in 2006. We can have that too, and we needn't wait for anything from RunRev - anyone with sufficient time and motivation can build this today. But somewhere along the way you'll eventually find
Re: Realbasic on the web without plugins
I agree with everything you wrote, but it cuts both ways: The things that make it hard to anyone to write HTML/JS/CSS apps also make it hard for RunRev to do. And similarly, the things that make it possible to write HTML/JS/CSS apps are things any of us can write today. If RunRev wants to take this on that would be convenient, but if not it's all just text so there's nothing stopping anyone from building this right now. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv Chipp wrote: Richard, If it were only JavaScript, I'd say, SURE, I'll take that bet! But it's not. It's the ever-changing landscape of xHtml, HTML5, JavaScript, various DOM versions, and it's about the vagaries and hassles in trying to create actual working decent cross browser CSS. Its about learning Apache components, and understanding caching techniques, and how to connect to different databases, each requiring their own flavor of SQL or other language. And learning about schemas and relational databases, how to set them up, how to access and optimize them. It's about learning when and how to write stored procedures, and in what language. It's about deciding what framework is best, and what other client side AJAX APIs you need to learn. And most importantly, it's about the full time job of trying to keep up with all this technology and the HUGE and RAPID changes that are being made. There are individuals whose full time job is just keeping up with CSS. There are companies who ONLY purpose is to convert a Photoshop layout to HTML/CSS. That's the beauty of LC. You only have to learn a single IDE, and you CAN develop for all these other platforms. If I thought it was as simple as typing a few lines of JavaScript, then I'd be there. Sadly, it's not. But, look what RB is doing. They allow you to create a RB application which runs fine on your desktop, then wrap it in a binary exe and run it AS IS on a server as a CGI. And it returns a perfectly formatted HTML, JavaScript, CSS full-featured cross browser solution, without the dreaded plugin. And without the need for me to be on top of the latest CSS browser hack which makes something look right in iOS Safari. Now, I know RB is nowhere near as flexible as LC, Jerry tells me you can't even change the color of the the text on a button without having to write a C-plugin, and don't even think about rolling your own controls, BUT... If they can figure out how to take a subset of their functionality and build a full functioning web app, then surely it's in the realm of possibility for LC? Just sayin'. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
I guess that's what's been in my mind throughout this thread - we're all pointing out how difficult it is to do this but RB have done it. I know nothing about other limitations of RB vs LC but it appears they have taken the lead in this one area. Pete Molly's Revenge http://www.mollysrevenge.com On Thu, Sep 22, 2011 at 11:12 PM, Chipp Walters ch...@chipp.com wrote: If they can figure out how to take a subset of their functionality and build a full functioning web app, then surely it's in the realm of possibility for LC? Just sayin'. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
I must agree. If I want to create web forms I can use a zillion tools. No, I want to create graphically rich apps that are multimedia driven or games. It's great that I can use live code for more mundane database programming as well, but I need the more complex stuff to work on mobile devices and the web. Mike Sent from my iPad On Sep 23, 2011, at 2:22 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Pete wrote: I guess that's what's been in my mind throughout this thread - we're all pointing out how difficult it is to do this but RB have done it. I know nothing about other limitations of RB vs LC but it appears they have taken the lead in this one area. In terms of perception, unquestionably. But in terms of actually moving projects to the web, it would require that one of us here use it to determine the degree of flexibility it provides. The video on the page linked to in the OP showed a relatively simple example, a master-detail form. How many of us *haven't* done that? Yes, that sort of thing can definitely be generalized easily. But then we have things like the stuff folks build using Malte's excellent Animation Engine. Can you write stuff like that in RB and have it automatically output the corresponding HTML/JavaScript/CSS to make it happen in a web browser? Or consider Jim Hurley's wonderful rainbow refraction stack. Or Richard Herz' Reactor Lab? Or Glenn Fisher's RobinHood? How much gets done on the server, and how much is done in the browser? To what degree can we fulfill expectations of putting LiveCode stacks on the Web if all that happens is that the server reproduces static layouts as minimally-interactive pages? Heck, how do you write a JS equivalent of LC's Geometry Manager to reposition things when the window gets resized? And how to do translate the thousands of resizeStack handlers we've all written? Doable, but not trivial. Very, very expensive, and responding to resize events is just a small corner of the breadth of tasks such a translation system would need to address. There are limits to what seems to be RB's approach. The server is only half of the equation. The user experience takes place in the browser, and all interactivity there is driven by only one language, JavaScript. Confining the range of interactions that can take place in pages generated by such a system is easily doable by anyone with time and motivation using nothing more than the tools we have in our hands right now. But to reproduce the full range of user experiences we can build in LiveCode inside of a browser is not a trivial task. I could be wrong, but I'd be very surprised if that's what RB/Web attempts. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
I don't know the answers to your questions Richard, except that the demo application does resize the controls when the window is resized. As for the other question, you're right none of us have given it a try so all it's all perception for now. Pete Molly's Revenge http://www.mollysrevenge.com On Fri, Sep 23, 2011 at 11:22 AM, Richard Gaskin ambassa...@fourthworld.com wrote: Pete wrote: I guess that's what's been in my mind throughout this thread - we're all pointing out how difficult it is to do this but RB have done it. I know nothing about other limitations of RB vs LC but it appears they have taken the lead in this one area. In terms of perception, unquestionably. But in terms of actually moving projects to the web, it would require that one of us here use it to determine the degree of flexibility it provides. The video on the page linked to in the OP showed a relatively simple example, a master-detail form. How many of us *haven't* done that? Yes, that sort of thing can definitely be generalized easily. But then we have things like the stuff folks build using Malte's excellent Animation Engine. Can you write stuff like that in RB and have it automatically output the corresponding HTML/JavaScript/CSS to make it happen in a web browser? Or consider Jim Hurley's wonderful rainbow refraction stack. Or Richard Herz' Reactor Lab? Or Glenn Fisher's RobinHood? How much gets done on the server, and how much is done in the browser? To what degree can we fulfill expectations of putting LiveCode stacks on the Web if all that happens is that the server reproduces static layouts as minimally-interactive pages? Heck, how do you write a JS equivalent of LC's Geometry Manager to reposition things when the window gets resized? And how to do translate the thousands of resizeStack handlers we've all written? Doable, but not trivial. Very, very expensive, and responding to resize events is just a small corner of the breadth of tasks such a translation system would need to address. There are limits to what seems to be RB's approach. The server is only half of the equation. The user experience takes place in the browser, and all interactivity there is driven by only one language, JavaScript. Confining the range of interactions that can take place in pages generated by such a system is easily doable by anyone with time and motivation using nothing more than the tools we have in our hands right now. But to reproduce the full range of user experiences we can build in LiveCode inside of a browser is not a trivial task. I could be wrong, but I'd be very surprised if that's what RB/Web attempts. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/**blog.irvhttp://LiveCodejournal.com/blog.irv __**_ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Folks, Speaking as someone who actually (tried to) build lots LC to Web tools I must say that the challenge is not rendering the controls or converting the language to javascript. That is not where the main issue lies. To convert LC to the Web, you would need what I call an LiveCode Kernel implemented in Javascript. This would be basically a reimplementation of the features we have in the engine such as message path, all the commands, all the functions, all the externals, all the controls, all of everything, in javascript. someting like: livecode.js Now, a translation process would begin by exporting the stackfile format to a json structure with all the properties and ownerships so that in the end you have a complete translation of all the data that is in the stackfile to a format that can be manipulated by javascript. With this json alone, you would be able to render the user interface but the scripts would require more work. Multiple steps would be needed to convert the scripts of the stack. They would be parsed into an AST of sorts, a graph or some storage medium that we could use to keep our representation of the script. This AST-like thing would then be exported to unoptimized javascript where all the LiveCode commands and functions are just wrapped in javascript calls so a script like: get totalTime add 1 to it put it into field total would be converted to: lc.env.it = totalTime; lc.env.it += 1; lcSetObjectProperty(lcObjectReference(field,total), text, lc.env.it ); You can see that there is no inteligence, it is a direct translation changing all that would be LiveCode commands to javascript wrappers. a global structure in the form of lc.env.* holds all the globals and special variables. A helper function lcSetObjectProperty() is used to set any object property using three parameters - the object reference, the property, the value. Another helper function picks an object type and a name and returns the reference that is used in the lcSetObjectProperty(); We're not translating LiveCode script to idiomatic Javascript, we're wrapping LiveCode semantics in a JavaScript syntax. This would be very slow but it would not be the hardest thing to build. Once you have a way to pick an alternative stackfile representation like a JSON file and you have all the engine features wrapped in your own javascript little kernel, you can convert stacks to the web. What many projects that boost their features as RAD tools for the web are doing is something different. Instead of translating their stuff to HTML+CSS+JS, what they do is wrap around the native program. They create a virtual screen on the browser where the output that would usually go to X11 or something similar is sent to the browser in a CANVAS tag or SVG or JPG. The raw mouse input such as coordinates and button status are constantly sent back to the server along with the keyboard status. The server maintain different client states for each connected user allowing the software to mimic it being run as different instances. This can be accomplished with closures and continuations. In this way, there is no conversion at all, you have a wrapper that pipes output to the browser and pushes browser input events to the server. All the logic and inteligence is on the server, there is nothing business related on the browser. This approach might sound more complicated but it is actually easier. Just google for GTK on the Web and you will see a GTK adapter that just do that. We can adopt that approach with LiveCode because we don't have multitasking or closures or continuations so the user state management would be really hard. The previous approach of reimplementing the engine in javascript and passing a stackfile representation around brings the logic and inteligence back to the browser and the server has no dealing with it anymore. It is a harder approach but it can be done. I started coding this during that Apple License fiasco we had where they prohibited all the non-objc languages on the appStore. I called the project RevImpossible and set a very slow pace. When apple reverted their license, I saw no use in trying to reimplement something that is so complex (it would take me years and a lot of smart people with me). I shifted RevImpossible to another focus, it still converts the visuals of stacks to the web but my focus is not the scripts anymore but a quick way to prototype websites using RevIgniter. My two cents PS: REALStudio Web thing appears to use FastCGI. I demoed a Revolution FastCGI library during RevConWest a long time ago... ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Once again, a truly wonderful post from Andre on a subject he knows deeply. The approach to translation through wrappers does indeed seem simpler than how I was envisioning, but also poses a question: Would RunRev really want to publish what would be a form of their engine in openly-readable JS? The other approach, a sort of virtualization, seems much simpler in many respects, a similar to Heizer's LiveCard (was that the name?) which ran HC as a sort of daemon process responding to minimal events over the socket. But unless I missed something, wouldn't that require a daemon, and therefore exclude pretty much all shared hosting options? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Thanks for such a clear explanation of what is involved, Andre! Pete Molly's Revenge http://www.mollysrevenge.com On Fri, Sep 23, 2011 at 12:13 PM, Andre Garzia an...@andregarzia.comwrote: Folks, Speaking as someone who actually (tried to) build lots LC to Web tools I must say that the challenge is not rendering the controls or converting the language to javascript. That is not where the main issue lies. To convert LC to the Web, you would need what I call an LiveCode Kernel implemented in Javascript. This would be basically a reimplementation of the features we have in the engine such as message path, all the commands, all the functions, all the externals, all the controls, all of everything, in javascript. someting like: livecode.js Now, a translation process would begin by exporting the stackfile format to a json structure with all the properties and ownerships so that in the end you have a complete translation of all the data that is in the stackfile to a format that can be manipulated by javascript. With this json alone, you would be able to render the user interface but the scripts would require more work. Multiple steps would be needed to convert the scripts of the stack. They would be parsed into an AST of sorts, a graph or some storage medium that we could use to keep our representation of the script. This AST-like thing would then be exported to unoptimized javascript where all the LiveCode commands and functions are just wrapped in javascript calls so a script like: get totalTime add 1 to it put it into field total would be converted to: lc.env.it = totalTime; lc.env.it += 1; lcSetObjectProperty(lcObjectReference(field,total), text, lc.env.it ); You can see that there is no inteligence, it is a direct translation changing all that would be LiveCode commands to javascript wrappers. a global structure in the form of lc.env.* holds all the globals and special variables. A helper function lcSetObjectProperty() is used to set any object property using three parameters - the object reference, the property, the value. Another helper function picks an object type and a name and returns the reference that is used in the lcSetObjectProperty(); We're not translating LiveCode script to idiomatic Javascript, we're wrapping LiveCode semantics in a JavaScript syntax. This would be very slow but it would not be the hardest thing to build. Once you have a way to pick an alternative stackfile representation like a JSON file and you have all the engine features wrapped in your own javascript little kernel, you can convert stacks to the web. What many projects that boost their features as RAD tools for the web are doing is something different. Instead of translating their stuff to HTML+CSS+JS, what they do is wrap around the native program. They create a virtual screen on the browser where the output that would usually go to X11 or something similar is sent to the browser in a CANVAS tag or SVG or JPG. The raw mouse input such as coordinates and button status are constantly sent back to the server along with the keyboard status. The server maintain different client states for each connected user allowing the software to mimic it being run as different instances. This can be accomplished with closures and continuations. In this way, there is no conversion at all, you have a wrapper that pipes output to the browser and pushes browser input events to the server. All the logic and inteligence is on the server, there is nothing business related on the browser. This approach might sound more complicated but it is actually easier. Just google for GTK on the Web and you will see a GTK adapter that just do that. We can adopt that approach with LiveCode because we don't have multitasking or closures or continuations so the user state management would be really hard. The previous approach of reimplementing the engine in javascript and passing a stackfile representation around brings the logic and inteligence back to the browser and the server has no dealing with it anymore. It is a harder approach but it can be done. I started coding this during that Apple License fiasco we had where they prohibited all the non-objc languages on the appStore. I called the project RevImpossible and set a very slow pace. When apple reverted their license, I saw no use in trying to reimplement something that is so complex (it would take me years and a lot of smart people with me). I shifted RevImpossible to another focus, it still converts the visuals of stacks to the web but my focus is not the scripts anymore but a quick way to prototype websites using RevIgniter. My two cents PS: REALStudio Web thing appears to use FastCGI. I demoed a Revolution FastCGI library during RevConWest a long time ago... ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to
Re: Realbasic on the web without plugins
On Fri, Sep 23, 2011 at 4:30 PM, Richard Gaskin ambassa...@fourthworld.comwrote: Once again, a truly wonderful post from Andre on a subject he knows deeply. Thanks for the kind words Richard!!! I only know something because I've been struggling with this for YEARS! The approach to translation through wrappers does indeed seem simpler than how I was envisioning, but also poses a question: Would RunRev really want to publish what would be a form of their engine in openly-readable JS? Yes this is something that RunRev would need to think of. A third party could build that after all we had HyperCard, SuperCard, OMO, Gain Momentum and other xTalk environments since a long time so people know how an xTalk engine should work. Making it support unique LiveCode stuff such as everything that starts with rev would be trickier because there is RunRev intellectual property involved. I am not building this anymore, it was too hard but a minimal set could be done. You don't need to support the datagrid and arcadeEngine but if a minimal set of LC is supported so that people can create master/details apps, then, why not? The other approach, a sort of virtualization, seems much simpler in many respects, a similar to Heizer's LiveCard (was that the name?) which ran HC as a sort of daemon process responding to minimal events over the socket. But unless I missed something, wouldn't that require a daemon, and therefore exclude pretty much all shared hosting options? You missed nothing, this would probably require a networked daemon if the application was to be kept running, or you went that far on virtualizing the stack, then you can probably save/restore state to disk between requests thus not needing a daemon but then, you better deal with all that load/restore state really quick during your cgi launch. Cheers andre -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/**blog.irvhttp://LiveCodejournal.com/blog.irv __**_ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://lists.runrev.com/mailman/listinfo/use-livecode -- http://www.andregarzia.com All We Do Is Code. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
On Fri, Sep 23, 2011 at 4:37 PM, Pete p...@mollysrevenge.com wrote: Thanks for such a clear explanation of what is involved, Andre! Don't take it as the platonic truth... that was my approach only and what I've seen thru the years. I bet there will be someone that will simply prove me wrong. Cheers and thanks for the kind words. andre Pete Molly's Revenge http://www.mollysrevenge.com On Fri, Sep 23, 2011 at 12:13 PM, Andre Garzia an...@andregarzia.com wrote: Folks, Speaking as someone who actually (tried to) build lots LC to Web tools I must say that the challenge is not rendering the controls or converting the language to javascript. That is not where the main issue lies. To convert LC to the Web, you would need what I call an LiveCode Kernel implemented in Javascript. This would be basically a reimplementation of the features we have in the engine such as message path, all the commands, all the functions, all the externals, all the controls, all of everything, in javascript. someting like: livecode.js Now, a translation process would begin by exporting the stackfile format to a json structure with all the properties and ownerships so that in the end you have a complete translation of all the data that is in the stackfile to a format that can be manipulated by javascript. With this json alone, you would be able to render the user interface but the scripts would require more work. Multiple steps would be needed to convert the scripts of the stack. They would be parsed into an AST of sorts, a graph or some storage medium that we could use to keep our representation of the script. This AST-like thing would then be exported to unoptimized javascript where all the LiveCode commands and functions are just wrapped in javascript calls so a script like: get totalTime add 1 to it put it into field total would be converted to: lc.env.it = totalTime; lc.env.it += 1; lcSetObjectProperty(lcObjectReference(field,total), text, lc.env.it ); You can see that there is no inteligence, it is a direct translation changing all that would be LiveCode commands to javascript wrappers. a global structure in the form of lc.env.* holds all the globals and special variables. A helper function lcSetObjectProperty() is used to set any object property using three parameters - the object reference, the property, the value. Another helper function picks an object type and a name and returns the reference that is used in the lcSetObjectProperty(); We're not translating LiveCode script to idiomatic Javascript, we're wrapping LiveCode semantics in a JavaScript syntax. This would be very slow but it would not be the hardest thing to build. Once you have a way to pick an alternative stackfile representation like a JSON file and you have all the engine features wrapped in your own javascript little kernel, you can convert stacks to the web. What many projects that boost their features as RAD tools for the web are doing is something different. Instead of translating their stuff to HTML+CSS+JS, what they do is wrap around the native program. They create a virtual screen on the browser where the output that would usually go to X11 or something similar is sent to the browser in a CANVAS tag or SVG or JPG. The raw mouse input such as coordinates and button status are constantly sent back to the server along with the keyboard status. The server maintain different client states for each connected user allowing the software to mimic it being run as different instances. This can be accomplished with closures and continuations. In this way, there is no conversion at all, you have a wrapper that pipes output to the browser and pushes browser input events to the server. All the logic and inteligence is on the server, there is nothing business related on the browser. This approach might sound more complicated but it is actually easier. Just google for GTK on the Web and you will see a GTK adapter that just do that. We can adopt that approach with LiveCode because we don't have multitasking or closures or continuations so the user state management would be really hard. The previous approach of reimplementing the engine in javascript and passing a stackfile representation around brings the logic and inteligence back to the browser and the server has no dealing with it anymore. It is a harder approach but it can be done. I started coding this during that Apple License fiasco we had where they prohibited all the non-objc languages on the appStore. I called the project RevImpossible and set a very slow pace. When apple reverted their license, I saw no use in trying to reimplement something that is so complex (it would take me years and a lot of smart people with me). I shifted RevImpossible to another focus, it still converts the visuals of
Re: Realbasic on the web without plugins
Le 23 sept. 2011 à 21:30, Richard Gaskin a écrit : The other approach, a sort of virtualization, seems much simpler in many respects, a similar to Heizer's LiveCard (was that the name?) which ran HC as a sort of daemon process responding to minimal events over the socket. If i right remember, it had to be started as a standard HC app and was communicating trough appelevents with WebSTAR 3 / MacOS 8 (single-threaded) I did't really use it even if i owned this tool ... -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
On Fri, Sep 23, 2011 at 9:58 AM, Richard Gaskin ambassa...@fourthworld.comwrote: I agree with everything you wrote, but it cuts both ways: The things that make it hard to anyone to write HTML/JS/CSS apps also make it hard for RunRev to do. And similarly, the things that make it possible to write HTML/JS/CSS apps are things any of us can write today. I agree. Of course it would make it hard for RunRev to do. But once done, we don't have to worry about it. Just like SiteGrinder ( http://www.medialab.com/) spits out compatible HTML CSS Javascript from Photoshop to all compatible browsers (iOS/Mac/PC/Chromebook). With SiteGrinder, I don't have to stay on top of the code idiosyncrasies, but can just focus on designing a website. The same is true with other high level web authoring systems, like NOLOH (http://www.noloh.com). The *whole point* is to provide an abstraction for HTML/Javascript and CSS-- just like the whole point in using LC to author cross compatible OS code-- you don't need to KNOW the API, or care about when it's changed. LC does the hard work for you so you can focus on the business end of things. That's the beauty. And regarding your comment about being able to do this today, please check out RB's web demo at: http://demos.realsoftware.com/cgi-bin/orders/orders.cgi#10046 Let me know if you can write that easily using HTML/JS/CSS and AJAX. If so, what JS framework would you use? And what database and connector? And how long would it take you to write it? (Notice it resizes with the browser window.) I can write that same thing in a day (minus the Google Map-- might take a bit more time) in Rev without a database connection. If I could then hit a button and create a CGI from it, where the data is stored as cards in a stack, then WOW. That's a winner product for sure. I know it won't be possible to create a complete mirror of the functionality of Rev. Andre knows this already. He provides 'symbols' or 'hints' in RevImpossible to indicate where a field can resize, or an image is a background. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Indeed so - and until/unless they do, there is a big hole in LiveCode's web deployment capability - and it'll only going to get bigger and affect more platforms if Windows 8 / IE10 does go down the no-plugins route. However, maybe they don't need to 'boil the whole ocean at once'. Whilst it would be great to simply deploy full-blown, native stacks as complete rich web apps, there are constraints imposed by the browser as a platform. So, is there any merit in starting with the basics - support for static LiveCode cards as forms? Could where specific cards in a LiveCode server stack be enabled with a subset of UI controls (with maybe a restricted property set in this context) and be embedded within HTML page template code elsewhere on the server? If moving parts were ignored (initially) don't most properties of LiveCode cards, fields, buttons, menus, images mapped to HTML and CSS parameters? Could JSON be used for custom properties? Could a set of standardised, minimal, Javascript utilities be used as client-side glue - maybe a RunRev jQuery library? Could the new cookies be used with this library to manage client states? Could moving parts be added subsequently with additional mappings of (a subset of LiveCode features) to standardised HTML, jQuery and Ajax? Obviously, any technical architect reading the above will realise that I've no idea what I'm talking about ;-) However, this it seems less than impossible - and with a modular KISS approach, some aspects seem relatively easy (at least to state the requirements!) But even if it isn't easy, if RunRev don't grasp the nettle on this, developers who must deploy standards-based rich apps into cloud and locked-down Enterprise environments will be forced elsewhere, which would be a shame. Best, Keith.. On 21 Sep 2011, at 23:53, Chipp Walters wrote: Yeah, it's certainly the mothership would have to take on... On Wed, Sep 21, 2011 at 2:54 PM, Andre Garzia an...@andregarzia.com wrote: Chipp, I tried doing something similar but the one point that I could not solve was how to maintain state for the different clients. Unless I converted everything to JS, then it was basically impossible. :-( Cheers andre On Wed, Sep 21, 2011 at 3:47 PM, Chipp Walters ch...@chipp.com wrote: http://www.realsoftware.com/web/ Looks to me like it compiles to a binary CGI which serves up the app as HTML/CSS/AJAX/Javascript/etc.. o. That's the solution for LC. Wouldn't it be cool to develop a modular website engine, which could easily be configured inside of RR? Or, take a really cool app, and put it on your server, accessible for anyone with a browser, including iPhone, Android, Chromebook, Linux, Windows 8.9 and 10? And-- not have to worry about stupid AppStores? o. -- Chipp Walters CEO, Shafer Walters Group, Inc. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- http://www.andregarzia.com All We Do Is Code. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Chipp Walters CEO, Shafer Walters Group, Inc. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Keith, Le 22 sept. 2011 à 09:56, Keith Clarke a écrit : Obviously, any technical architect reading the above will realise that I've no idea what I'm talking about ;-) The only constraint to get in mind to achieve your proposal in a clean and rock-solid way is that the stack's to html+dom+js+css translated component will by definition become a multi-users application and this is what makes this project a little more complex - but full doable ! - task than just having simple stack's cards converted to html+dom+js+css widgets. However, this it seems less than impossible - and with a modular KISS approach, some aspects seem relatively easy (at least to state the requirements!) But even if it isn't easy, if RunRev don't grasp the nettle on this, developers who must deploy standards-based rich apps into cloud and locked-down Enterprise environments will be forced elsewhere, which would be a shame. Again, this project is suitable in using LC to build the needed framework but this will need some time and invests to achieve the project in the needed professional-grade way. Best, Keith.. Best, -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Thanks for the sense-check Pierre - good to know that the concept isn't pure fantasy! :-) Yes, there is some complexity, but given what the RunRev team are achieving with the engine, iOS and Android ports and LiveCode Server, I'm certain that they could solve this - given the appropriate awareness, appetite, capacity and business case to act. My point is that RunRev wouldn't necessarily need to sell-off the family silver to fund development of a basic, useful, standards-based web deployment toolkit - one that wouldn't take forever to realise. Best Keith.. On 22 Sep 2011, at 11:18, Pierre Sahores wrote: Keith, Le 22 sept. 2011 à 09:56, Keith Clarke a écrit : Obviously, any technical architect reading the above will realise that I've no idea what I'm talking about ;-) The only constraint to get in mind to achieve your proposal in a clean and rock-solid way is that the stack's to html+dom+js+css translated component will by definition become a multi-users application and this is what makes this project a little more complex - but full doable ! - task than just having simple stack's cards converted to html+dom+js+css widgets. However, this it seems less than impossible - and with a modular KISS approach, some aspects seem relatively easy (at least to state the requirements!) But even if it isn't easy, if RunRev don't grasp the nettle on this, developers who must deploy standards-based rich apps into cloud and locked-down Enterprise environments will be forced elsewhere, which would be a shame. Again, this project is suitable in using LC to build the needed framework but this will need some time and invests to achieve the project in the needed professional-grade way. Best, Keith.. Best, -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
If only the web deployment module could output to either Ajax, Air, Flex or HTML5 this would no longer be an issue. Mike On Thu, 22 Sep 2011 11:44:02 +0100, Keith Clarke wrote: Thanks for the sense-check Pierre - good to know that the concept isn't pure fantasy! :-) Yes, there is some complexity, but given what the RunRev team are achieving with the engine, iOS and Android ports and LiveCode Server, I'm certain that they could solve this - given the appropriate awareness, appetite, capacity and business case to act. My point is that RunRev wouldn't necessarily need to sell-off the family silver to fund development of a basic, useful, standards-based web deployment toolkit - one that wouldn't take forever to realise. Best Keith.. On 22 Sep 2011, at 11:18, Pierre Sahores wrote: Keith, Le 22 sept. 2011 à 09:56, Keith Clarke a écrit : Obviously, any technical architect reading the above will realise that I've no idea what I'm talking about ;-) The only constraint to get in mind to achieve your proposal in a clean and rock-solid way is that the stack's to html+dom+js+css translated component will by definition become a multi-users application and this is what makes this project a little more complex - but full doable ! - task than just having simple stack's cards converted to html+dom+js+css widgets. However, this it seems less than impossible - and with a modular KISS approach, some aspects seem relatively easy (at least to state the requirements!) But even if it isn't easy, if RunRev don't grasp the nettle on this, developers who must deploy standards-based rich apps into cloud and locked-down Enterprise environments will be forced elsewhere, which would be a shame. Again, this project is suitable in using LC to build the needed framework but this will need some time and invests to achieve the project in the needed professional-grade way. ww seil.com ___ use-livecode mailing list use-livecode@lists.runrev.com [1] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode [2] Links: -- [1] mailto:use-livecode@lists.runrev.com [2] http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
...the issue is that there is currently no LiveCode web deployment module - there's only the proprietary, thick-client, LiveCode Player browser plugin, with its specific OS and browser dependencies. Hopefully, the RunRev team won't replace their Player with alternative proprietary thick-client technologies (such as Air or Flex). This would seem a retrograde step, especially when these competitor's technologies also face the challenge of supporting non-desktop web client devices, with smarter browsers, richer standards-based technologies to hand and pressure on plugins. This seems to be shaping-up like most technology trends over the last few decades - the early days of proprietary technology innovation (and lock-in) eventually get supplanted by the chasing pack that gang-up and force market consolidation onto more open standards. In this case the 'VHS' seems to be HTML5/CSS/Javascript. Those who don't adopt or adapt, will retrench back into niches markets or fall by the wayside. So, it will be interesting to see what the RunRev team have to say on this matter when they eventually break the silence on their web deployment plans. They have been very quiet in this area, though LiveCode Server did slip out into general release under the covering fire of all the iOS and Android 'there's gold in them there hills' announcements. Who knows, LiveCode server might just prove to be a vital component in the web deployment strategy. The one certainty is that the LiveCode Player is now showing its age and is in urgent need of overhaul or replacement. It would be surprising (and somewhat disappointing) if there isn't something better being cooked-up. Best, Keith.. On 22 Sep 2011, at 14:04, Admin wrote: If only the web deployment module could output to either Ajax, Air, Flex or HTML5 this would no longer be an issue. Mike ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Keith Clarke wrote: But even if it isn't easy, if RunRev don't grasp the nettle on this, developers who must deploy standards-based rich apps into cloud and locked-down Enterprise environments will be forced elsewhere, which would be a shame. I wrote about this last year: http://lists.runrev.com/pipermail/use-livecode/2011-June/157979.html Like too many of my posts that's a long one, but it represents pretty much everything I came up with that's relevant to the discussion, and I've been thinking about this a long time since two of my biggest projects are all about the web and are based in LiveCode. In short: There are two sides to this, client and server. On the server side RunRev has already provided what may be the most cost-effective solution for that with RevServer. But the client is a whole other game, fully immersed not only in a very different language but also in a deeply well-defined object model that, in many respects, bears little resemblance to LiveCode's. We use LiveCode because a good scripting language lets us build things more quickly than we could do in a lower-level language like C. But JavaScript is not a low-level language. It's almost as high-level as LiveCode, and as well integrated into the object model it supports as LiveCode is with its own. But the object models are very different. Attempting full translation of LiveCode to JavaScript would not be impossible, but very expensive. IMO, when you consider the limitations inherent in such a task, it's probably much more expensive than just learning JavaScript. That said, there are many opportunities for using LiveCode to generate some portions of the client-side experience for the web. A starting point was outlined here in 2006: http://lists.runrev.com/pipermail/use-livecode/2006-June/083956.html I haven't used the RB/web implementation, but I'd be surprised if it did full RB-JavaScript translation; my guess is that the server side is very much like RevServer and the client side is like the ToolBook approach I outlined in 2006. We can have that too, and we needn't wait for anything from RunRev - anyone with sufficient time and motivation can build this today. But somewhere along the way you'll eventually find limitations between what LiveCode can do on the desktop and what a translation to a different object model will be able to do on the web. There's more to apps than forms. And for those you'll want to use JavaScript. Fortunately, it's kinda fun to learn and there are orders of magnitude more resources for that than we have for all the things we've learned about LiveCode. Dive in, the water's fine. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Hello Richard, Le 22 sept. 2011 à 16:39, Richard Gaskin a écrit : Attempting full translation of LiveCode to JavaScript would not be impossible, but very expensive. IMO, when you consider the limitations inherent in such a task, it's probably much more expensive than just learning JavaScript. To stay full compliant with the best client-side JS libs (JQuey, MooTools, Prototype, Sliderman, etc...), i expect that a direct map from the LC client-side code to javascript would not be the most economical way to go. I would prefer instead to have (1) the LC client-side code mapped to the LC server-side code and (2) the LC server-side code mapped to HTML template's blocks (stored on the server's file system to stay updatable on demand) where (3) only those HTML template's blocks would have to be linked to JS/Ajax libs. This design purpose is the way widestep.fr is build on. Hope that my sad english is, at least, readable on the main idea ;-) Best regards, -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
On Wed, Sep 21, 2011 at 2:47 PM, Chipp Walters wrote: http://www.realsoftware.com/web/ Looks to me like it compiles to a binary CGI which serves up the app as HTML/CSS/AJAX/Javascript/etc.. o. That's the solution for LC. Wouldn't it be cool to develop a modular website engine, which could easily be configured inside of RR? Or, take a really cool app, and put it on your server, accessible for anyone with a browser, including iPhone, Android, Chromebook, Linux, Windows 8.9 and 10? And-- not have to worry about stupid AppStores? o. -- Chipp Walters CEO, Shafer Walters Group, Inc. Awesome idea, but a tremendous undertaking. A few have tried before, and some of them made good progress, but then... http://tilestack.com/ ~Roger ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Chipp, I tried doing something similar but the one point that I could not solve was how to maintain state for the different clients. Unless I converted everything to JS, then it was basically impossible. :-( Cheers andre On Wed, Sep 21, 2011 at 3:47 PM, Chipp Walters ch...@chipp.com wrote: http://www.realsoftware.com/web/ Looks to me like it compiles to a binary CGI which serves up the app as HTML/CSS/AJAX/Javascript/etc.. o. That's the solution for LC. Wouldn't it be cool to develop a modular website engine, which could easily be configured inside of RR? Or, take a really cool app, and put it on your server, accessible for anyone with a browser, including iPhone, Android, Chromebook, Linux, Windows 8.9 and 10? And-- not have to worry about stupid AppStores? o. -- Chipp Walters CEO, Shafer Walters Group, Inc. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- http://www.andregarzia.com All We Do Is Code. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
I have to admit, this realbasic thing has piqued my interest - not just the web part of it but the whole package. Has anyone on the list taken a look at it? Pete Molly's Revenge http://www.mollysrevenge.com On Wed, Sep 21, 2011 at 3:53 PM, Chipp Walters ch...@chipp.com wrote: Yeah, it's certainly the mothership would have to take on... On Wed, Sep 21, 2011 at 2:54 PM, Andre Garzia an...@andregarzia.com wrote: Chipp, I tried doing something similar but the one point that I could not solve was how to maintain state for the different clients. Unless I converted everything to JS, then it was basically impossible. :-( Cheers andre On Wed, Sep 21, 2011 at 3:47 PM, Chipp Walters ch...@chipp.com wrote: http://www.realsoftware.com/web/ Looks to me like it compiles to a binary CGI which serves up the app as HTML/CSS/AJAX/Javascript/etc.. o. That's the solution for LC. Wouldn't it be cool to develop a modular website engine, which could easily be configured inside of RR? Or, take a really cool app, and put it on your server, accessible for anyone with a browser, including iPhone, Android, Chromebook, Linux, Windows 8.9 and 10? And-- not have to worry about stupid AppStores? o. -- Chipp Walters CEO, Shafer Walters Group, Inc. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- http://www.andregarzia.com All We Do Is Code. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Chipp Walters CEO, Shafer Walters Group, Inc. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
Haven't gotten involved in the Web Edition yet, but use RS on a regular basis. On 09/21/2011 4:36 PM, Pete wrote: I have to admit, this realbasic thing has piqued my interest - not just the web part of it but the whole package. Has anyone on the list taken a look at it? Pete -- David Glass - Gray Matter Computing graymattercomputing.com Help Desk: http://www.graymattercomputing.com/helpdesk 559-303-4915 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Realbasic on the web without plugins
At $1000 for enterprise, its a bit expensive for me (but I would need the cross platform and web capability). Mike Pete p...@mollysrevenge.com wrote: I have to admit, this realbasic thing has piqued my interest - not just the web part of it but the whole package. Has anyone on the list taken a look at it? Pete Molly's Revenge http://www.mollysrevenge.com On Wed, Sep 21, 2011 at 3:53 PM, Chipp Walters ch...@chipp.com wrote: Yeah, it's certainly the mothership would have to take on... On Wed, Sep 21, 2011 at 2:54 PM, Andre Garzia an...@andregarzia.com wrote: Chipp, I tried doing something similar but the one point that I could not solve was how to maintain state for the different clients. Unless I converted everything to JS, then it was basically impossible. :-( Cheers andre On Wed, Sep 21, 2011 at 3:47 PM, Chipp Walters ch...@chipp.com wrote: http://www.realsoftware.com/web/ Looks to me like it compiles to a binary CGI which serves up the app as HTML/CSS/AJAX/Javascript/etc.. o. That's the solution for LC. Wouldn't it be cool to develop a modular website engine, which could easily be configured inside of RR? Or, take a really cool app, and put it on your server, accessible for anyone with a browser, including iPhone, Android, Chromebook, Linux, Windows 8.9 and 10? And-- not have to worry about stupid AppStores? o. -- Chipp Walters CEO, Shafer Walters Group, Inc. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- http://www.andregarzia.com All We Do Is Code. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Chipp Walters CEO, Shafer Walters Group, Inc. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
