Terry, Thank you for your thoughtful reply. A couple of thoughts crossed my mind while reading it.
Years ago, in a former life, I used to attend various CEO conferences. At one of them, I had a chance to visit with Eric Schmidt, now of Google, but then he was with Sun. We got to talking about Java, the topic of the day. My comment to him was, as a multimedia company, we had evaluated Java and determined it was too slow and too abstracted to do any meaningful development with. He remarked, yes, he already knew this. But more important than the reality of what Java currently was, is the expectation and perception of what it will be. His point to me was the perception is more important the the nuts and bolts of reality. I think the same is true for HTML5. When a client says they want an HTML5 application, most don't really know what it is they want, nor do they know the trade-offs which may be necessary to provide a lowest common denominator application. But they do know they need it to run on the web, and on browsers connected to iPads and Androids and Macs and PCs. As a strategy component for the client, and even more importantly for us developers, we MUST have a RAD tool for HTML5 apps-- or if not HTML5, then AJAXy "look like application and not websites" apps. Most clients don't know the difference. If we don't heed this, my guess is we will run out of clients and projects as they end up moving to the web or isolated platforms. The other key point is perhaps a lesson learned from Jerry and Sarah. Here in Austin, I see Jerry often. In fact I'm having lunch with him tomorrow. One thing Jerry always understood when he developed applications, is to start simple. His RodeoApps did just that. I'm saying we do the same. Start by creating a card and a button with a home icon...and go from there. That said, RodeoApps is not what I'm talking about. I'm not talking about a subscription based model where all code lives on a server. HTML5 allows for caching. I actually suggesting the opposite approach, where you start on the client and load an HTML5 app there and do simple things. Just like Rev. Early on, it only did simple things-- even now you can't code Photoshop or MS Word in it. I'm thinking the same with an HTML5 plugin approach. I get it there will be some hurdles, and one of them will have to be a compile (translate) first approach-- not unlike many other IDE's including our own LC iOS plugin. Still, the time is now, not AFTER all HTML5 problems are worked out-- or pushed out to HTML6. Sorta like the guy who never bought a TV because he was waiting for the new and better one to come out in just a few months. Just my 2 cents. _______________________________________________ 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