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
