Raju, what do you need the API compatibility for? > With the increasing focus on Ajax/DHTML
Focus by whom? Did I understand correctly, Raju, that you would like to see flash runtime dropped? Or did you mean that API's of laszlo need to converge with the W3C dhtml APIs? > Call me a nut, but I have some vain hope that swfN and HTMLn will eventually > converge and we won't > have to waste engineering cycles making them look the > same. I hope this would come true. It would be good for the business, developers, everybody. But, but, but ... I think that the powers that be, have decided that Adobe can not be given advantage. That's what we saw happening with ECMAScript 4th edition crash landing. See, there is a risk that Flash would become the de facto Web application platform. Browser would be just a container for flash platform (and practically everybody would have it ... hey 97% already do). Without a doubt Flash is much more advanced than dhtml. You can do games with Flash. Surely that means that you can do business applications with it (although the convenience libraries might be missing). The issue is, on which future does one bet? If Microsoft et al. win the game the penetration of flash drops before the developing world have time to pick up on flash. In the other event people start writing their applications on Flash and Adobe wins. This of course requires open sourcing flash (which Adobe is desparately trying to do with great reluctance). Because it means cutting off your cash cows in the risky hope of having a bigger future. This brings me to the question, what is the role of laszlo in all of this? Is it the platform for those who do not have the courage to bet on a horse? Now comes today's hard fact: You always bet on a horse, whether you think so or not. To me it seems that the starting point of laszlo was: "Let's do a way better Ajax platform by using flash instead of dhtml." Maybe because of Adobe's setback in getting the approval from the establishment Laszlo has (wisely & cowardly I might add) also started to support dhtml and reinvented it's value proposition: "Can't choose between dhtml and flash? Use Laszlo." Now the first value proposition became harder to realize, namely: "Want to develop more 'cinematic' webapps than your partner? Choose Laszlo." Because now you had to make it work on dhtml too and that kind of defeats the initial purpose. I think Raju is questioning the second value proposition. He says that with the advent of dhtml 5 it also becomes dupious. So what would be laszlo's new value proposition? If I could choose I would say let's go back to flash only and bet on that horse. But then again I am a compulsive loser. I am fooled by constant delusions of a better future. And that's why I always end up betting on the losing horse. I would have developed everything with Java but Java could not succeed with the penetration issue. Hey maybe I should develop with java....@#* penetration I am doing business apps here. At this point comes the enhancement of the 2nd value proposition: "Can't choose between dhtml, flash, java fx or silverlight? Have a laszlo." But most likely this will choke on it's own pomposity. Can be realized only on paper. I think that the open source community should embrace flash platform if it were to be completely open sourced. If Adobe does not do it flash is dead. But then you have these nerds in the linux community who are hard headed fundamentalist (inflexible and stupid). Saying "my way or high way" secretly crying out the pain of being sent packing on the highway... With the triumph of one technology over a committee monster, reason and science would have a victory over bureaucracy. And that is always good for the developers. Remember SQL, brothers in arms? Now there you have a committee monster. Oh, but I got lost in the maze of my own thoughts. Greetings from Amsterdam, Rami 25.1.2010 21:52, P T Withington kirjoitti: Call me a nut, but I have some vain hope that swfN and HTMLn will eventually converge and we won't have to waste engineering cycles making them look the same. Instead we can spend our engineering cycles raising the level of abstraction in OpenLaszlo making it a more powerful language than the underlying runtimes so that you can solve complex problems without worrying about gritty details. In the short term, we need to strike a balance between exposing only the lowest common denominator features and locking applications into only one platform. I think we have done a fairly good job of this so far, mostly because we have been driven by what the OL programmer needs, not by just implementing the next cool thing and exposing every knob and dial at the OL API. We do try very hard to follow standards where possible. But if forced to make a choice between a /de facto/ (proprietary) standard like SWF and a draft (but open) standard like HTML5, I would choose the open standard. That said, we are not against building on standards where necessary, to make OpenLaszlo a more powerful tool. We adopted (and extended) the as3 class extensions to Javascript before they were accepted into Javascript. Now the Javascript standards bodies are starting to revisit the topic of classes in Javascript. We may find ourselves out on a limb, but we should be able to adapt -- we've done it before! On 2010-01-25, at 15:20, Raju Bitter wrote: With the increasing focus on Ajax/DHTML - going in hand with nice new HTML5 features - the evolving W3C standards are going to have a strong influence on the LZX APIs in future versions of OpenLaszlo. Until now SWFx and AS2/3 have been the runtime providing many more features for OpenLaszlo than the browsers' JS engines. That's changing right now, and the question is: How is OpenLaszlo going to incorporate the HTML5 APIs into LZX? Take Flash SharedObject (https://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/net/SharedObject.html) and W3C WebStorage (http://www.w3.org/TR/webstorage/) as an example: How are we going to create APIs providing those features across runtimes? If there similar functionalities in SWFx and HTML5/W3C standards, are we going to create a common API for - using the example of local storage - key-value pairs in DHTML using WebStorage, and duplicating that behavior in SWFx using SharedObject functionality? Or is the focus going to be on open standard based features which will be accessible from within SWFs through SWF->JavaScript calls? A powerful feature would be the capability to define the runtime environment for a method/script as an attribute to the method or script. Imagine code like this inside a SWFx runtime app: <method name="storeNote" runtime="javascript" args="id,title,body"> // Some JavaScript code using the WebStorage API to store a note // This method would be turned into a JavaScript function inside the browser // Any call to this method would be passed from the SWF app to the JS function </method> If the same app is compiled as DHTML, passing of method calls would not be necessary. I'd be interested in hearing what you think, or what your ideas are for OL apps using many of the new JS/HTML5/W3C features. - Raju
