Slashdot Mirror

For what it's worth, Flash is open. I wrote a few simple apps in raw flex, and some much more complex ones with Open Laszlo. True, Adobe opened it up in a desperate (and largely successful) bid to survive Silverlight. The openness of Flash made it possible for me to write this, so all and all I can't complain. Not as a developer anyway.

Regarding Flex, I was hoping for an open standard.

You might want to look into OpenLaszlo.

apparently, your concepts of how to use flash are quite limited. as a matter of fact, the *applications* i write are often full (browser) screen flash apps with nothing else on the page. it's okay, i understand you've been bombarded by so many flash ads and you simply must conceive of the platform as nothing more then banners and video games and video playback. but you're wrong and get yourself past the mundane: http://openlaszlo.org/ your welcome.

but there are 3 (that I can name!) next generation javascript frameworks that may help:

GWT -- google's java to javascript translator.

Sproutcore -- Apple is using it for .Mac

Cappuccino -- more or less complete reimplementation of Cocoa via objective javascript

I'll also mention OpenLazlo, though I haven't paid any attention to it, so I don't know the internals.

that's why I love support and cherish openlaszlo and variants as the sane choice for non-semantic web applications of which there is large need. HTML+css is fine for publications and static searchable content (e.g. craigslist), and a barrier to entry for everything else. check it: http://openlaszlo.org/

I think OpenLaszlo is going to eat Flex and Silverlight lunch because it's multi-runtime.

The same code generates identical apps in DHTML, Flash or potentially any other runtime.

Well, I will throw out there a heads up to folks about OpenLaszlo which is the "run-anywhere, no-lock-in rich Internet platform. Period."

That's not entirely true. OpenLaszlo relies on Flash to display video, and Flash is not a no-lock-in platform. You cannot redistribute Flash, or use it in a whole host of applications without licensing it from Adobe.

... in a bid to take on Adobe's Flash and Microsoft's Silverlight technologies

Well, I will throw out there a heads up to folks about OpenLaszlo which is the "run-anywhere, no-lock-in rich Internet platform. Period."

Unfortunately it still has a massive adoption curve ahead of it so maybe there's no reason to list it as a contender. While there are neat demos, a few companies have employed it: Wal-Mart, Pandora even MSN's music service.

*sigh* I wonder if this means Sun is going to pull out of Orbit and come up with some J2ME version of JavaFX?

Like always, I welcome the competition, diversity and options this brings while I cringe at the thought of yet another schism in the open source community.

... in a bid to take on Adobe's Flash and Microsoft's Silverlight technologies

Well, I will throw out there a heads up to folks about OpenLaszlo which is the "run-anywhere, no-lock-in rich Internet platform. Period."

Unfortunately it still has a massive adoption curve ahead of it so maybe there's no reason to list it as a contender. While there are neat demos, a few companies have employed it: Wal-Mart, Pandora even MSN's music service.

*sigh* I wonder if this means Sun is going to pull out of Orbit and come up with some J2ME version of JavaFX?

Like always, I welcome the competition, diversity and options this brings while I cringe at the thought of yet another schism in the open source community.

This meta-article and the whole style of discussion proves it once again in so many ways: To many n00bs claim to much of a say in Web-developenent. Especially among the ones programming a lot but actually knowing squat about web-developement and it's specialties. That something like this goes as an expertise story shows the downside of the field. It's like the entire imature discussion, indifferent raving and bashing about Ajax or RoR or some other recent fad in the field.

To clear a few things up

1) MVC is a construct to describe the most basic setup when using a seperate persistance layer in an end-user application. The concept has been around for at least 15 years and is most certainly *not* limited to web-developement. On contrary, it's basically a relatively simple model for 90ies style GUI DB Apps. For modern web-developement fanatically sticking to MVC is a severe restriction, as in a web-app with seperate persistance, the controller - due to stateless connection to the UI (Browser) - needs to be seperated into at least 2 tiers to make any sense at all, thus turning a pure 3-tier MVC approach into more of a hinderance than a support in webapps.

2) Moving the view layer into client-side logic (if it's in MVC or something else is of no concern) is nothing new. The concept has been around since the dawn of computer networking and is - of course - also a natural progression for web-apps and a growing availability of umbiquious zero-fuss rich-client funtionality (read: non-trivial standardised JavaScript client-server stuff (aka 'Ajax') nowadays works in most Browsers). In many ways the pure server side stuff in web-logic of the last 10 years was an exception and intermediate solution paid for with huge server overhead in order to offer statefull sorta-kinda-GUI-apps in software purpose built for something completely different: Reading documents (aka 'Browsers'). Java was an attempt to get the real thing but it didn't catch on for various reasons. The main being crappy plattform deployment to end-users. That's why - strangely enough for Java enthusiasts - Java still is competing with Flash in that respect.

3) Client-side logic doesn't break MVC. As explained above, MVC has nothing to do wether the app resides on the client, the server or is spread out between. In fact, the most sophisticated frameworks that rely on rich-client functionality do that seperation as the most natural result. Openlaszlo (that which Adope ripped off in Flex) and Tibco GI come to mind as prime examples for that. And both have been around for quite some time now.

As a senior web-developer with solid experience I love the fact that the entire field is very good at regularly offering solid ripostes of result oriented work to any academic arrogance the field of computer science and programming. Thus the ongoing success of PHP-based web-apps. However, it appears that this is taken as an excuse - by professionals just as much as novices - to babble out and present anything they ran accross and haven't fully looked into yet as the newest insight in the field. I sometimes wish people would stop, do some research and then think before they post an opinion that isn't even thought through to the end. Customers and novices interested in the field for whatever reason are confused enough as it is.

My 2 cents.

I have Flash on my Nokia N800. It has no noticeable effect on battery life.

I use OpenLaszlo to develop auditing software that has earned me a very good living for the past few years. The auditing apps are very utilitarian in use and appearance, despite running on Flash.

My language of use for the past 3 years, OpenLaszlo has brilliant doco right there on the site. With a reference guide that lists all the objects, methods and events with live, editable examples for many.

And then if the documentation doesn't cover what you want, there's the great forums which have helped me out of plenty of sticky coding situations.

The doco was what drew us to OpenLaszlo in the first place. Well, that and the fact it's open source helped a lot!

My language of use for the past 3 years, OpenLaszlo has brilliant doco right there on the site. With a reference guide that lists all the objects, methods and events with live, editable examples for many.

And then if the documentation doesn't cover what you want, there's the great forums which have helped me out of plenty of sticky coding situations.

The doco was what drew us to OpenLaszlo in the first place. Well, that and the fact it's open source helped a lot!

My language of use for the past 3 years, OpenLaszlo has brilliant doco right there on the site. With a reference guide that lists all the objects, methods and events with live, editable examples for many.

And then if the documentation doesn't cover what you want, there's the great forums which have helped me out of plenty of sticky coding situations.

The doco was what drew us to OpenLaszlo in the first place. Well, that and the fact it's open source helped a lot!

Next step is that we shall be able to see a server-side compiled JavaScript

If you're talking about servers sending precompiled bytecode in place of javascript, no that isn't the next step or even on the agenda. Unless that is you have a VM in javascript.

In that case we will be able to have language-agnostic browsers since the compiled code won't necessarily have to reflect which language that was used to write the script.

You don't need bytecode for that.

• http://haxe.org/doc/intro
• http://www.openlaszlo.org/
• http://code.google.com/p/pyjamas/
• http://code.google.com/webtoolkit/

Let's spell it out, some want to use the CLR for web applications (I'm never installing Mono). Some don't like the fact that web client apps in javascript are inherently open source. Seems to me that there are more compelling reasons not to standardize on a common bytecode.

Flash apps must be developed in ActionScript, and must developed in IDEs specifically designed for Flash - of which there are about 3.

No, some alternatives exists such as:

• haXe which is a compiler that target the Flash VM (among others).
• OpenLaszlo

Slashdot post that talks about RIA technologies, mentions Silverlight and doesn't say anything about OpenLaszlo? What should we expect from Microsoft then...

Traditional web apps are slow, because of all the chatting with a server. But well made AJAX, and frameworks like this one and OpenLazlo, http://www.openlaszlo.org/ are changing that.

Makes me wonder... Maybe soon(ish) a lot of apps which are now strictly in the desktop domain will really be viable through a browserlike environment?

I've been quite skeptical myself, but every time I see something like this it makes me wonder if I'm just not seeing the true possibilities...

Yes, you're wrong.

It's a shame you spent so much effort writing all that and none on Googling, because there is plenty of information out there.

Adobe's own application platform for Flash is Flex. OpenLaszlo is an open-source XML based programming language for developing apps in SWF. Flash itself also has a substantial component collection for app development, and finally, there are dozens of third-party ActionScript IDEs and compliers available.

That's why Microsoft is introducing Silverlight. Flash is threatening to become an OS-independent application platform which could make Windows irrelevant.

Mostly more control and better programming. OpenLaszlo, which is briefly mentioned in TFA, is an XML/javacript based programming language which compiles to Flash and/or DHTML. It includes a bunch of APIs for things like layout, data binding and server communication, and is one of the easiest prototyping tools I've ever used.

The slogan is "write once, run everywhere", which may be familiar to some older Slashdotters, but it's not too far off the truth. I'm using it now to develop auditing apps for the Nokia N800/810 internet tablets, and it's impressively simple.

If you're interested, I'd suggest you download it and try it, or check out the tutorial. It's very easy to get started, and the tutorial compiles and runs your code online.

Mostly more control and better programming. OpenLaszlo, which is briefly mentioned in TFA, is an XML/javacript based programming language which compiles to Flash and/or DHTML. It includes a bunch of APIs for things like layout, data binding and server communication, and is one of the easiest prototyping tools I've ever used.

The slogan is "write once, run everywhere", which may be familiar to some older Slashdotters, but it's not too far off the truth. I'm using it now to develop auditing apps for the Nokia N800/810 internet tablets, and it's impressively simple.

If you're interested, I'd suggest you download it and try it, or check out the tutorial. It's very easy to get started, and the tutorial compiles and runs your code online.

Then use OpenLaszlo.

Their competition has barely started.

The problem Google Apps and similar online suites are going to run into is that it's easy to develop special-purpose document creation tools with OpenLaszlo and similar dev tools.

At the moment, it makes sense to use a stand-alone office suite because even just writing the most common document format requires heavy code and resources. Once ODF becomes ubiquitous, it'll make more sense to equip users with tools appropriate to their roles and minimise the use of resource intensive general-purpose suites.

Having never programmed Flash, I just have this question: since Flash is pretty much everywhere, wouldn't just programming your site in Flash be a better option?

A pox on thy house! May you and your family suffer from those fungal infestations that make your toenails look like cauliflower. For fuck's sake, FLASH?

Have you checked out Open Laszlo? It sounds like it might be what you're looking for. (I'm not affiliated with them in any way. I just think it's an interesting project.)

I just took a look as OpenLaszlo again (it's been a while) and it looks nice. Maybe a bit shakey, though... Their 'introduction' page/app didn't load properly on linux (Opera) the first time, and UI ended up looking at just a 'wait' clock. Reloading brought it up.

The calendar demo doesn't work well either, as I've been completely unable to add an event (can't type, looks like there are missing controls) under Opera and Firefox, even if I try to reload it.

Also, http://www.openlaszlo.org/lps/laszlo-explorer/index.jsp?navset=nav10.xml&bookmark=Introduction looks quite slow. I see at the bottom that it's recompiling each time, but that's not immediately obvious.

Other than that, it looks promising. I just recommended we buy an app at work that will let us make video tutorials in flash quite quickly, but if I can learn that fast enough, I may change the recommendation... I'll have to take a closer look.

I think (might wrong about this) but http://www.openlaszlo.org/ might a good way to degrade. It will create similar interfaces in both flash and dhtml. So you can detect if a user has flash if so give them flash if not give them dhtml. Of course (and this the part I have wondered myself) why not just always use dhtml?

The screencast shows live object/entity linking through a bloated RIA interface that probably needs a 3 GHz CPU and a 400$ GFX card to render properly. Let alone an MS operating system and their bloated, insecure, barely beta and closed-source proprietary silverthingie stuff.
The rotating entitiy cubes are pointless, anoying and distracting and are probably just there to hide the fact that we are basically looking at a RIA case tool with a restricted featureset. Everybody knows that things are going this way, but I doubt MS will get all things right to capture a larger audience and developer base.
Meanwhile I'm sticking with Laszlo for true cross-plattform RIA developement. After all even Adobe Flex is scrambling to catch up with them. And Laszlo went completely open source way before anybody else.

Someone at Apache, IBM, or Sun announce that they are going to introduce a truely cross platform, open source, and Free alternative to Silverlight and Flash.

Just off the top of my head there's SVG as a potential format. I think a standard exists for turning XML into binary or hexadecimal (WBXML? WBML? I can't remember what it was called) for optimization. After that you need a set of tools to make content development easy. I suppose you could look towards OpenLaszlo for a model on the programming end. In other words, JavaScript + XML compiling to SVG (it's more complex and so shouldn't be dealt with directly) and then to the optimized form. InkScape, if it's mature enough, could be used for the actual graphical assets. I have no idea what could replace Flash's embedded video, but this might be a good opportunity for the Theora codec (if it ever gets out of alpha).

You're right that there would need to be a big push by a powerful entity, though. It's a matter of visibility plus follow-through, I think.

The OpenLazlo TFA mentioned in passing looks kind of interesting, at least enough to check out further. The source for their demos looks pretty clean and straightforward.

OpenLaszlo, a opensource toolkit that takes declaritive XML and compiles it to SWF. What it can do for datasets and backend interactivity is just awesome. Recommended cause it's neat plus it's way saner then HTML (imho), as long you're doing applications and not semantic stuff, this is where it's at. mmm. replication managers.

http://www.openlaszlo.org/

Uses XML/Javascript to drive either Flash or DHTML.

Some of their examples are pretty good, while other examples could have used a QA person.

1.) This process is generally regarded as 'generating' rather than compiling. Compiling implies that something is transferred into a lower level language for speed and better runtime integration. Here it's the opposite. Thus: Generating. The servlet (or whatever) does it is generically refered to as 'generator'. Compiling is the wrong term.

2.) Prior Art. Tons of it. Laszlo and a bunch of other generators have been doing this for years. This patent won't even last a month. To many big players involved in RIA to let it pass. It's about as long lasting (and as silly) as the famous Gary Larson 'Chicken hung by a helium balloon floating into a pub full of Samurai'. Nothing new here, move on.

That's not a bad thing.

I'm very interested in this. It could potentially make OpenLaszlo the tool of choice for quickie desktop applications. Rapid, clean and easy prototyping - what's not to like?

Python's Kid template system is proof that you're wrong about XML template systems always being a pain in the ass. I've used it to write a whole lot of complex templates, and I'm very happy with it, and will continue using it. I've also used XSLT, TAL/METAL/TALES in Plone, and Smarty in PHP, and they are all total pains in the ass which I hope to avoid ever using in the future. If you had some perspective on other templating systems, you'd know that hiding commands in processing instructions or cdata is NOT the only way to make them easier. Designing clean simple consistent yet powerful XML based languages is the way to make them easier, and that's what Kid is. OpenLaszlo is another example of a well designed XML based programming language that is easy to use because it's well designed.

At least I'm criticizing and complementing systems that I've actually used. You're just making wild guesses about things you know nothing about, and your guesses are wrong.

I know Smarty translates templates into PHP -- I've read the source code and used it. Kid translates templates into Python, and I've read that source code and used it too. Kid's approach to XML processing is a much more elegent, efficient, better designed than Smarty's ad-hoc string parsing based approach, by a long shot. Go back and read the source code to both systems yourself, and use them for non-trivial projects like I have, before shooting your mouth off about them when you don't know what you're talking about.

Again: Why bother implementing an extremely bad languge like Smarty in a very bad language like PHP? You can't argue that Smarty's syntax is any better than PHP or XML. So why use Smarty at all? Why not just stick with pure PHP? There is no need for Smarty. It doesn't solve any problems that PHP doesn't already solve. It just introduced another fucked-up quirky syntax you have to learn, which makes PHP even harder to use.

And no your could not implement a system like Kid in PHP easily or efficiently, because it's based on XML event handling using Python's generators, which PHP does not support. Kid transformations are easy to write because they use generators with "yield" and "next" in co-routines running in parallel, to efficiently produce and consume XML events, so you can write straightforward procedural code with local variables, conditionals and loops, without writing SAX-like handlers and putting all temporary state into objects. Generators are a language feature that is extremely useful for efficiently processing XML, and they can't be implemented by a library: they have to be built into the language. PHP does not have generators, and I doubt it ever will.

Generator: In computer science, a generator is a special routine that can be used to control the iteration behaviour of a loop. A generator is very similar to a function that returns an array, in that a generator has parameters, can be called, and generates a sequence of values. However, instead of building an array containing all the values and returning them all at once, a generator yields the values one at a time, which requires less memory and allows the caller to get started processing the first few values immediately. In short, a generator looks like a function but behaves like an iterator.

In Python, a generator can be thought of as an iterator that contains a frozen stack frame. Whenever the iterator's next() method is called, Python resumes the frozen frame, which executes normally until the next yield statement is reached. The generator's frame is then frozen again, and the yielded value is returned to the caller.

Smarty is purely string based, and not at all XML compliant, and makes no guarantees about the validity of its input or output. XMLReader's detailed description is "This class can be used to parse XML documents and build an array with structure and data.

You said it yourself: Web Apps are the obvious answer. I build enterprise apps base on OSS and while there are solutions out there (GNU Enterprise, Compiere) a good modern zero fuss turnkey kit doesn't exist. It's the same as with proprietary Enterprise Software. They're all so hermetric and well entrenched in their market that they couldn't care less about getting agile.
Get youself an OSS savy webapp developer/consultant, have him look at your data and build what you need to fill the growing gaps. If you tell him to build around standards, use existing components and foster an OSS spinnoff from the deal you'll be doing some good along the side. A good professional progammer that isn't arrogant with management and accounting will speed up internal processes for you along the way as a bonus.

Option: Then again you might just go and talk with your vendor. 400+ people isn't a small company and if you catch the right people you might even convince them to rethink their 'Active X ERP' strategy.

Yet then again: Who in Gods name builds an Enterprise Application requireing Active X??? Might aswell drop the vendor all together...

The farthest I'd go in the Web interface is use Flash (and only optional) to ease the pageflow pain. And I'd only do that because I've built ERP Apps before using flash and - believe it or not - they work pretty well on Linux, OS X and Windows. If you know what your doing. Which, sadly enough, only very few Flash devs actually do.
Another big thing of course is using Open Office as the corner stone. Can hardly go wrong using that.

Utter shameless Plug: If you need consulting or evaluation on the matter of OSS (web) ERP I'd be glad to help. You'll find my contact data on my Website under 'Kontakt'. I'm in Germany but I've allready done successfull ERP projects across the pond (entirely remote) and allways am glad for projects that cross-fund web-bases OSS ERP. I'd love to get an occasion to give OpenLaszlo a try on this.

The problem with Real, QuickTime, Windows Media and all the other video players, is that all they are just stupid video players boxed into a rectangular prison, and not customizable or adaptable in any way. You can't add to their user interface, or fix their horrible design problems. No control over how closed captioning is presented. No transparent video overlays. No extra buttons or links to related videos. No webcam support or two-way video conferencing.

From a user interface design perspective, Flash has an enormous advantage over old-school video players, because developers are able to deeply customize and integrate the video player into their own user interfaces, like Google's and YouTube's video players, the OpenLaszlo YouTube player, or the SimFaux Network TV Fox News Simulation.

The other overwhelming advantage to Flash over all the other video players, is that it's installed on way more platforms than any other existing video player. So the fact that it has almost universal coverage, plus the fact that you can customize the user interface (like YouTube, Google Video, and everyone else does), combine to make Flash the hands-down best way to distribute video over the internet.

Here's an example of what I mean by customization: A set of reusable video playback and recording components that I've developed for OpenLaszlo, which are easy to customize and integrate into your own OpenLaszlo applications:

OpenLaszlo YouTube Player Demo and Source Code

I've been working on developing streaming video support for OpenLaszlo: LZX classes to support improved audio and video, including RTMP streaming via Flash Media Server (aka Flash Communication Server) and also the Red5 Open Source Flash Server, as well as streaming video via http. It supports playback of recorded FLVs, recording from camera and microphone, live two-way (or multi-party) audio/video conferencing, and FLV streaming over http.

It's easy to use the OpenLaszlo video components, because they're nicely integrated with the OpenLaszlo programming model. They expose logical attributes and events which make it easy to integrate video into OpenLaszlo applications.

To test it out the code and demonstrate its functionality, I've developed a simple YouTube Player in OpenLaszlo [click here to open it in a window]. It uses the YouTube ReST Web API, and some simple html screen scraping to get the URL parameters to stream the FLV file directly.

Here is the source for the test application wrapper that puts the YouTube video player in a resizable window, and the more interesting source for the youtubeplayer component, that uses the new OpenLaszlo video classes I'm developing (whose source is in this directory).

The new video classes and the YouTube player demo are now checked into the OpenLaszlo svn repository.

The problem with Real, QuickTime, Windows Media and all the other video players, is that all they are just stupid video players boxed into a rectangular prison, and not customizable or adaptable in any way. You can't add to their user interface, or fix their horrible design problems. No control over how closed captioning is presented. No transparent video overlays. No extra buttons or links to related videos. No webcam support or two-way video conferencing.

From a user interface design perspective, Flash has an enormous advantage over old-school video players, because developers are able to deeply customize and integrate the video player into their own user interfaces, like Google's and YouTube's video players, the OpenLaszlo YouTube player, or the SimFaux Network TV Fox News Simulation.

The other overwhelming advantage to Flash over all the other video players, is that it's installed on way more platforms than any other existing video player. So the fact that it has almost universal coverage, plus the fact that you can customize the user interface (like YouTube, Google Video, and everyone else does), combine to make Flash the hands-down best way to distribute video over the internet.

Here's an example of what I mean by customization: A set of reusable video playback and recording components that I've developed for OpenLaszlo, which are easy to customize and integrate into your own OpenLaszlo applications:

OpenLaszlo YouTube Player Demo and Source Code

I've been working on developing streaming video support for OpenLaszlo: LZX classes to support improved audio and video, including RTMP streaming via Flash Media Server (aka Flash Communication Server) and also the Red5 Open Source Flash Server, as well as streaming video via http. It supports playback of recorded FLVs, recording from camera and microphone, live two-way (or multi-party) audio/video conferencing, and FLV streaming over http.

It's easy to use the OpenLaszlo video components, because they're nicely integrated with the OpenLaszlo programming model. They expose logical attributes and events which make it easy to integrate video into OpenLaszlo applications.

To test it out the code and demonstrate its functionality, I've developed a simple YouTube Player in OpenLaszlo [click here to open it in a window]. It uses the YouTube ReST Web API, and some simple html screen scraping to get the URL parameters to stream the FLV file directly.

Here is the source for the test application wrapper that puts the YouTube video player in a resizable window, and the more interesting source for the youtubeplayer component, that uses the new OpenLaszlo video classes I'm developing (whose source is in this directory).

The new video classes and the YouTube player demo are now checked into the OpenLaszlo svn repository.

The problem with Real, QuickTime, Windows Media and all the other video players, is that all they are just stupid video players boxed into a rectangular prison, and not customizable or adaptable in any way. You can't add to their user interface, or fix their horrible design problems. No control over how closed captioning is presented. No transparent video overlays. No extra buttons or links to related videos. No webcam support or two-way video conferencing.

From a user interface design perspective, Flash has an enormous advantage over old-school video players, because developers are able to deeply customize and integrate the video player into their own user interfaces, like Google's and YouTube's video players, the OpenLaszlo YouTube player, or the SimFaux Network TV Fox News Simulation.

The other overwhelming advantage to Flash over all the other video players, is that it's installed on way more platforms than any other existing video player. So the fact that it has almost universal coverage, plus the fact that you can customize the user interface (like YouTube, Google Video, and everyone else does), combine to make Flash the hands-down best way to distribute video over the internet.

Here's an example of what I mean by customization: A set of reusable video playback and recording components that I've developed for OpenLaszlo, which are easy to customize and integrate into your own OpenLaszlo applications:

OpenLaszlo YouTube Player Demo and Source Code

I've been working on developing streaming video support for OpenLaszlo: LZX classes to support improved audio and video, including RTMP streaming via Flash Media Server (aka Flash Communication Server) and also the Red5 Open Source Flash Server, as well as streaming video via http. It supports playback of recorded FLVs, recording from camera and microphone, live two-way (or multi-party) audio/video conferencing, and FLV streaming over http.

It's easy to use the OpenLaszlo video components, because they're nicely integrated with the OpenLaszlo programming model. They expose logical attributes and events which make it easy to integrate video into OpenLaszlo applications.

To test it out the code and demonstrate its functionality, I've developed a simple YouTube Player in OpenLaszlo [click here to open it in a window]. It uses the YouTube ReST Web API, and some simple html screen scraping to get the URL parameters to stream the FLV file directly.

Here is the source for the test application wrapper that puts the YouTube video player in a resizable window, and the more interesting source for the youtubeplayer component, that uses the new OpenLaszlo video classes I'm developing (whose source is in this directory).

The new video classes and the YouTube player demo are now checked into the OpenLaszlo svn repository.

Relax NG has a compact non-XML syntax. But C++/Java is a horrible syntax to use if you want a language to be readable and easy to understand. Since when was 17 levels of operator precedence easy to understand? Of course any good programmer always uses parenthesis to avoid ambiguity, so why should a language have 17 levels of built-in ambiguity just to make it that much easier to make hard to find mistakes?

-Don

From my blog: Relax NG Compact Syntax: no to operator precedence, yes to annotations!

James Clark is a fucking genius! Hes the guy who wrote the Expat XML parser, works on Relax NG, and does tons of other important stuff. Relax NG is an ingeniously designed, elegant XML schema language based on regular expressions, which also has a compact, convenient non-xml syntax.

I totally respect the way he throws down the gauntlet on operator precedence (take that you Perl and C++ weenies!):

There is no notion of operator precedence. It is an error for patterns to combine the |, &, , and - operators without using parentheses to make the grouping explicit. For example, foo | bar, baz is not allowed; instead, either (foo | bar), baz or foo | (bar, baz) must be used. A similar restriction applies to name classes and the use of the | and - operators. These restrictions are not expressed in the above EBNF but they are made explicit in the BNF in Section 1.

You can translate back and forth between Relax NG's XML and compact syntaxes with full fidelity, without losing any important information. Relax NG supports annotating the grammar with standard and custom namespaces, so you can add standard extensions and extra user defined meta-data to the grammar. That's useful for many applications like user interface generators, programming tools, editors, compilers, data binding, serialization, documentation, etc.

Here's an interesting example of a complex Relax NG application: OpenLaszlo is an XML/JavaScript based programming language, which the Laszlo compiler translates into SWF files for the Flash player. The Laszlo compiler and programming tools use this lzx.rnc Relax NG schema for the OpenLaszlo XML language. This schema contains annotations used by the Laslzo compiler to define the syntax and semantics of the XML based programming language.

The schema starts out by defining a few namespaces:

default namespace = "http://www.laszlosystems.com/2003/05/lzx"
namespace rng = "http://relaxng.org/ns/structure/1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1 .0"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
namespace lza = "http://www.laszlosystems.com/annotations/1.0"

The a: namespace defines some standard annotations like a:defaultValue, and the lza: namespace defines some custom annotations private to the Laszlo compiler like lza:visibility and lza:modifiers. Thanks to the ability to annotate the grammar, much of the syntax and semantics of the Laszlo programming language are defined directly in the Relax NG schema in the compact syntax, so any other tool can read the exact same definition the compiler is using!

To show how truly simple and elegant it is, here is the snake eating its tail: The Relax NG XML syntax, written in the Relax NG compact syntax:

# RELAX NG XML syntax specified in compact syntax.

default namespace rng = "http://relaxng.org/ns/structure/1.0"
namespace loc

You can certainly learn the value of the platform without paying for a seminar. The development platform is free since it's open source, and it doesn't cost anything to read the online documentation, the wiki, and get involved with the community.

Of course there are differences between the capabilities of different platforms. OpenLaszlo is most mature on Flash, which runs identically on all platform and browsers, and has great graphics and multimedia capabilities. The DHTML/JavaScript version of OpenLaszlo runtime relies on the Dojo Toolkit JavaScript AJAX library to achieve cross-browser compatibility. The J2ME version of OpenLaszlo uses the Rhino JavaScript interpreter, and its own graphics library, but it's only in the early development stages.

There's an Eclipse based IDE for OpenLaszlo (developed by IBM), and some tools for Emacs as well.

OpenLaszlo inherits the limitations of the delivery platform, so there are some limitations that apply to Flash and other limitations that apply to DHTML. But the API is purposefully designed to hide the differences between platforms, instead of exposing platform specific APIs directly (like the way Adobe's FLEX is designed to lock you into Flash).

-Don

You can certainly learn the value of the platform without paying for a seminar. The development platform is free since it's open source, and it doesn't cost anything to read the online documentation, the wiki, and get involved with the community.

Of course there are differences between the capabilities of different platforms. OpenLaszlo is most mature on Flash, which runs identically on all platform and browsers, and has great graphics and multimedia capabilities. The DHTML/JavaScript version of OpenLaszlo runtime relies on the Dojo Toolkit JavaScript AJAX library to achieve cross-browser compatibility. The J2ME version of OpenLaszlo uses the Rhino JavaScript interpreter, and its own graphics library, but it's only in the early development stages.

There's an Eclipse based IDE for OpenLaszlo (developed by IBM), and some tools for Emacs as well.

OpenLaszlo inherits the limitations of the delivery platform, so there are some limitations that apply to Flash and other limitations that apply to DHTML. But the API is purposefully designed to hide the differences between platforms, instead of exposing platform specific APIs directly (like the way Adobe's FLEX is designed to lock you into Flash).

-Don

You can certainly learn the value of the platform without paying for a seminar. The development platform is free since it's open source, and it doesn't cost anything to read the online documentation, the wiki, and get involved with the community.

Of course there are differences between the capabilities of different platforms. OpenLaszlo is most mature on Flash, which runs identically on all platform and browsers, and has great graphics and multimedia capabilities. The DHTML/JavaScript version of OpenLaszlo runtime relies on the Dojo Toolkit JavaScript AJAX library to achieve cross-browser compatibility. The J2ME version of OpenLaszlo uses the Rhino JavaScript interpreter, and its own graphics library, but it's only in the early development stages.

There's an Eclipse based IDE for OpenLaszlo (developed by IBM), and some tools for Emacs as well.

OpenLaszlo inherits the limitations of the delivery platform, so there are some limitations that apply to Flash and other limitations that apply to DHTML. But the API is purposefully designed to hide the differences between platforms, instead of exposing platform specific APIs directly (like the way Adobe's FLEX is designed to lock you into Flash).

-Don

Using XML micro-formats is a more dynamic and flexible approach than persistent objects. Your data is much too important to tie it directly to the internal implementation of one particular version of one particular class.

The approach that OpenLaszlo takes is XML data binding and declarative constraints. You design XML "micro formats" for your data, and then you can write many different views and editors of the same data, by binding different OpenLaszlo classes to the XML data with XPath constraints and JavaScript expressions. (As well as methods and event handlers written in JavaScript, declared in XML).

That way you can have many different viewers and editors that are compatible with the same XML data, and you can use constraints and JavaScript to bind and tailor off-the-shelf and custom widgets together with the XML data. JavaScript constraints are automatically updated when the values they depend on are changed. The two-way XPath data binding between the XML and the OpenLaszlo objects automatically updates the XML and all other views bond to the same data.

It's not just old-school cargo-cult MVC. OpenLaszlo uses a more powerful, general purpose, easier to use approach: data binding (XPath), declarative constraints (JavaScript), with a prototype based class system.

-Don

OpenLaszlo is a great way to write "AJAXian" dynamically downloaded componentized data driven applications, that run in the Flash player and DHTML/JavaScript browsers (and eventually the J2ME Java VM).

For many years, I've been building distributed data driven scriptable user interfaces, and evangelizing what's now called the "AJAX" architecture. Here are some old articles I wrote about X, NeWS and TCL in the 80's and 90's. Note that in this context "server" means window server (your desktop: once called the window server, now called the browser client), not web server (the remote system running the application: once called the application client, now called the web server).

-Don

From comp.windows.x, 1989 and xpert@athena, 1987:

From: Don Hopkins (don@brillig.umd.edu)
Date: Tues, Sep 19 1989 8:08 am
Groups: comp.windows.x

I think it's a pretty good idea to have the window manager, or some other process running close to the server, handle all the menus. Window managment and menu managment are separate functions, but it would be a real performance win for the window and the menu manager to reside in the same process. There should be options to deactivate either type of managment, so you could run, say, a motif window manager, and an open look menu manager at the same time. But I think that in most cases you'd want the uniform user interface, and the better performance, that you'd get by having both in one process.

I think it would be possible to implement something like this with the NDE window manager in X11/NeWS. It's written in object oriented PostScript, based on the tNt toolkit, and runs as a light weight processes inside the NeWS server. This way, selecting from a menu that invokes a window managment function only involves one process (the xnews server), instead of three (the x server and the two "outboard" managers), with all the associated overhead of paging, ipc, and context switching.

Here's a message on a related subject that I sent to xpert a couple years back (before I'd heard of the ICCCM). I never did get much response, except that one person pointed out that that was precisely the problem that NeWS was designed to solve. ;-)

c(-; Once were done forging the menu manager standard, how about we do text editors, huh?)

-Don

Date: Mon, 23 Feb 87 18:31:00 EST
From: Don Hopkins don@brillig.umd.edu
To: ru...@ucbvax.berkeley.edu
Cc: xpert@athena.mit.edu
Subject: Uwm extensions, perhaps?

Date: 23 Feb 87 19:44:43 GMT From: ru...@ucbvax.berkeley.edu (Rusty Wright)

Marvin Solomon writes:

What's the solution? I think it is to get rid of the idea of window manager as a separate process, and build "window-manager" functions into all windows.

That scares me. Wouldn't we then have the problem that suntools has where the suntool binaries are huge? On my sun 3/50 the suntools program itself is 728 blocks and the various other tools that run under suntools are 952 blocks. Yuck.

How about setting up some sort of standard? For example, all window managers must use control+shift when the mouse is in a window or an icon, and when it's in the background the control+shift is optional.

rusty c. wright r...@weyl.berkeley.edu

I see just the same problem with XToolKit. I would like to see the ToolKit as a client that you would normally run on the same machine as the server, for speed. Interactive widgets would be much more interactive, you wouldn't have to have a copy of the whole library in every client, and there would be just one client to con

OpenLaszlo is a great way to write "AJAXian" dynamically downloaded componentized data driven applications, that run in the Flash player and DHTML/JavaScript browsers (and eventually the J2ME Java VM).

For many years, I've been building distributed data driven scriptable user interfaces, and evangelizing what's now called the "AJAX" architecture. Here are some old articles I wrote about X, NeWS and TCL in the 80's and 90's. Note that in this context "server" means window server (your desktop: once called the window server, now called the browser client), not web server (the remote system running the application: once called the application client, now called the web server).

-Don

From comp.windows.x, 1989 and xpert@athena, 1987:

From: Don Hopkins (don@brillig.umd.edu)
Date: Tues, Sep 19 1989 8:08 am
Groups: comp.windows.x

I think it's a pretty good idea to have the window manager, or some other process running close to the server, handle all the menus. Window managment and menu managment are separate functions, but it would be a real performance win for the window and the menu manager to reside in the same process. There should be options to deactivate either type of managment, so you could run, say, a motif window manager, and an open look menu manager at the same time. But I think that in most cases you'd want the uniform user interface, and the better performance, that you'd get by having both in one process.

I think it would be possible to implement something like this with the NDE window manager in X11/NeWS. It's written in object oriented PostScript, based on the tNt toolkit, and runs as a light weight processes inside the NeWS server. This way, selecting from a menu that invokes a window managment function only involves one process (the xnews server), instead of three (the x server and the two "outboard" managers), with all the associated overhead of paging, ipc, and context switching.

Here's a message on a related subject that I sent to xpert a couple years back (before I'd heard of the ICCCM). I never did get much response, except that one person pointed out that that was precisely the problem that NeWS was designed to solve. ;-)

c(-; Once were done forging the menu manager standard, how about we do text editors, huh?)

-Don

Date: Mon, 23 Feb 87 18:31:00 EST
From: Don Hopkins don@brillig.umd.edu
To: ru...@ucbvax.berkeley.edu
Cc: xpert@athena.mit.edu
Subject: Uwm extensions, perhaps?

Date: 23 Feb 87 19:44:43 GMT From: ru...@ucbvax.berkeley.edu (Rusty Wright)

Marvin Solomon writes:

What's the solution? I think it is to get rid of the idea of window manager as a separate process, and build "window-manager" functions into all windows.

That scares me. Wouldn't we then have the problem that suntools has where the suntool binaries are huge? On my sun 3/50 the suntools program itself is 728 blocks and the various other tools that run under suntools are 952 blocks. Yuck.

How about setting up some sort of standard? For example, all window managers must use control+shift when the mouse is in a window or an icon, and when it's in the background the control+shift is optional.

rusty c. wright r...@weyl.berkeley.edu

I see just the same problem with XToolKit. I would like to see the ToolKit as a client that you would normally run on the same machine as the server, for speed. Interactive widgets would be much more interactive, you wouldn't have to have a copy of the whole library in every client, and there would be just one client to con

The OpenLaszlo Legals Project will benefit immensely from this! OpenLaszlo is in a position to take excellent advantage of the now open source AMV2 JavaScript engine, for the benefit of users as well as developers. Not only will AVM2 make OpenLaszlo applications run faster on Firefox, but opening up the AVM2 virtual machine will make it possible to develop much more powerful debuggers and integrated development environments.

-Don

What is OpenLaszlo "Legals"?

"Legals" is an OpenLaszlo project to provide a single application environment that supports multiple deployment runtimes. OpenLaszlo 3.x supports Flash 7 and 8 now, but Legals will extend that reach to include DHTML as well as Flash 9. And with the necessary infrastructure in place, we anticipate further runtimes will be developed by the OpenLaszlo community.

The OpenLaszlo "Legals" project began at the start of 2006. We are projecting final availability by the end of the year. Developers interested in helping make Legals a reality are invited to contact us. Developers wishing to get a head-start building applications on top of Legals will be able to do so with our beta release in a few months.

Many people ask about the back story for the project name. The name, Legals, is a tribute to a well-known local restaurant in Boston where a lunch meeting inspired the team to launch this project.

See Legals FAQ for commonly asked questions and answers.

The Architecture

With Legals, the OpenLaszlo architecture is being remodularized into a true multi-runtime platform. OpenLaszlo generates script source that is compatible with ECMAScript Release 3, while leveraging extensions from ECMAScript Release 4. From there, multiple compiler backends generate JavaScript in the native dialect of the destination runtime: ActionScript 2 or 3, JScript 5.6, JavaScript 1.4+, and so on.

The OpenLaszlo runtime library is being refactored into two parts: multiple kernels containing runtime-specific code, and a cross-runtime library written in standard ECMA-3. As part of the runtime library, the OpenLaszlo class system has been rewritten in ECMA-3 and includes several innovative new features.

The OpenLaszlo runtime library delivers a common baseline of functionality across all supported runtimes. This gives the developer a rich environment in which to build full-featured web applications. In addition, Legals will include runtime-specific extensions so that the particular benefits of targeting a runtime are not lost to the OpenLaszlo application developer.

The OpenLaszlo Legals Project will benefit immensely from this! OpenLaszlo is in a position to take excellent advantage of the now open source AMV2 JavaScript engine, for the benefit of users as well as developers. Not only will AVM2 make OpenLaszlo applications run faster on Firefox, but opening up the AVM2 virtual machine will make it possible to develop much more powerful debuggers and integrated development environments.

-Don

What is OpenLaszlo "Legals"?

"Legals" is an OpenLaszlo project to provide a single application environment that supports multiple deployment runtimes. OpenLaszlo 3.x supports Flash 7 and 8 now, but Legals will extend that reach to include DHTML as well as Flash 9. And with the necessary infrastructure in place, we anticipate further runtimes will be developed by the OpenLaszlo community.

The OpenLaszlo "Legals" project began at the start of 2006. We are projecting final availability by the end of the year. Developers interested in helping make Legals a reality are invited to contact us. Developers wishing to get a head-start building applications on top of Legals will be able to do so with our beta release in a few months.

Many people ask about the back story for the project name. The name, Legals, is a tribute to a well-known local restaurant in Boston where a lunch meeting inspired the team to launch this project.

See Legals FAQ for commonly asked questions and answers.

The Architecture

With Legals, the OpenLaszlo architecture is being remodularized into a true multi-runtime platform. OpenLaszlo generates script source that is compatible with ECMAScript Release 3, while leveraging extensions from ECMAScript Release 4. From there, multiple compiler backends generate JavaScript in the native dialect of the destination runtime: ActionScript 2 or 3, JScript 5.6, JavaScript 1.4+, and so on.

The OpenLaszlo runtime library is being refactored into two parts: multiple kernels containing runtime-specific code, and a cross-runtime library written in standard ECMA-3. As part of the runtime library, the OpenLaszlo class system has been rewritten in ECMA-3 and includes several innovative new features.

The OpenLaszlo runtime library delivers a common baseline of functionality across all supported runtimes. This gives the developer a rich environment in which to build full-featured web applications. In addition, Legals will include runtime-specific extensions so that the particular benefits of targeting a runtime are not lost to the OpenLaszlo application developer.

The OpenLaszlo Legals Project will benefit immensely from this! OpenLaszlo is in a position to take excellent advantage of the now open source AMV2 JavaScript engine, for the benefit of users as well as developers. Not only will AVM2 make OpenLaszlo applications run faster on Firefox, but opening up the AVM2 virtual machine will make it possible to develop much more powerful debuggers and integrated development environments.

-Don

What is OpenLaszlo "Legals"?

"Legals" is an OpenLaszlo project to provide a single application environment that supports multiple deployment runtimes. OpenLaszlo 3.x supports Flash 7 and 8 now, but Legals will extend that reach to include DHTML as well as Flash 9. And with the necessary infrastructure in place, we anticipate further runtimes will be developed by the OpenLaszlo community.

The OpenLaszlo "Legals" project began at the start of 2006. We are projecting final availability by the end of the year. Developers interested in helping make Legals a reality are invited to contact us. Developers wishing to get a head-start building applications on top of Legals will be able to do so with our beta release in a few months.

Many people ask about the back story for the project name. The name, Legals, is a tribute to a well-known local restaurant in Boston where a lunch meeting inspired the team to launch this project.

See Legals FAQ for commonly asked questions and answers.

The Architecture

With Legals, the OpenLaszlo architecture is being remodularized into a true multi-runtime platform. OpenLaszlo generates script source that is compatible with ECMAScript Release 3, while leveraging extensions from ECMAScript Release 4. From there, multiple compiler backends generate JavaScript in the native dialect of the destination runtime: ActionScript 2 or 3, JScript 5.6, JavaScript 1.4+, and so on.

The OpenLaszlo runtime library is being refactored into two parts: multiple kernels containing runtime-specific code, and a cross-runtime library written in standard ECMA-3. As part of the runtime library, the OpenLaszlo class system has been rewritten in ECMA-3 and includes several innovative new features.

The OpenLaszlo runtime library delivers a common baseline of functionality across all supported runtimes. This gives the developer a rich environment in which to build full-featured web applications. In addition, Legals will include runtime-specific extensions so that the particular benefits of targeting a runtime are not lost to the OpenLaszlo application developer.