Introducing Legals
Late last week, the OpenLaszlo project reached a huge milestone: release of the first source snapshot of our multiple-runtimes architecture, code named "Legals". The purpose of this snapshot is to deliver infrastructure, tools, and architecture sufficient to allow broad community participation in the project.
We began Legals back in January because we felt it was finally time to invest in OpenLaszlo's potential as a multi-runtime application framework. Adobe had released an initial beta of Flash 9 (then called Flash 8.5), and it was clear to us that it would be essentially an entirely new VM: new bytecode set, many improvements
to the ActionScript language, and substantially revised APIs. In order to support Flash 9 we would need to build a new compiler backend and new runtime libraries.
Simultaneously, the Ajax movement had been gathering steam and we thought that we had a window of opportunity to deliver a DHTML runtime as well. Ironically, the high cost of entry for Flash 9 created a situation where entering the DHTML/Ajax market had become relatively affordable, because the infrastructure work required could be amortised over two runtimes instead of just one. So we decided to do both: Flash 9 would create exciting new opportunities for the existing OpenLaszlo community, while DHTML would introduce OpenLaszlo to a new community and create a much larger market for OpenLaszlo application development.
(The fact that we have not talked about Flash 9 until now is partly engineering risk reduction and partly messaging. We wanted to begin with the most different runtime first—DHTML—in order to reduce risk as quickly as possible. We also knew that the DHTML announcement would be the bigger story and wanted to keep our marketing message simple.)
Simultaneously, we had been planning a set of infrastructure upgrades to improve project transparency and quality. In particular, our source control database was still behind the Laszlo Systems firewall and our build system was overly complex. The decision to do Legals put more urgency on these plans since our potential pool of contributors was about to become much larger.
After showing the potential of our approach in March with the LZPIX demo, we felt that the next step should be to fully open the project to community participation. So we decided that we would aim for an initial snapshot release with three
distinct goals:
- Put in place the fundamentals of a multi-runtime architecture;
- Port our development tools to the first new runtime target (DHTML); and
- Invest in improved community-oriented project infrastructure.
And we have delivered on all three of these goals. With this snapshot, the basic architecture supporting multiple runtime targets is in place. We have the necessary development tools in place for both Flash 7/8 and DHTML, including a very nice debugging console in DHTML. And we have converted to an externally-available Subversion source repository and largely rewritten our build system.
The details are available on the Legals project page, but here is the headline message: if you'd like to help out with one of the most exciting, challenging web application framework projects on the planet, now is the time. Get involved!.
June 27th, 2006 at 4:03 pm
Footnote:
Here is how I remember the derivation of the project name “legals” (since several have asked in other places): Jim and the west coast members of the OpenLaszlo team had come to Cambridge, MA to meet with the east-coast members of the team for a 1-day architectural status meeting.
In the morning, the decision before us was whether to put efforts into supporting Flash 9 or DHTML. There were strong opinions on both sides. We took a break for lunch, at the Legal Seafoods Restaruant near Harvard Square. The lunch, originally budgeted for 1 hour, ended up taking 3 hours, and during that time the decision was made: “What the hell. Let’s do both.”
Jim Grandy suggested the project name “legals” in honor of the luncheon at which this decision was made.
Other participants at the lunch that day may remember things slightly differently.
June 27th, 2006 at 8:48 pm
very cool - haven’t tinkered since 3.0- looking forward to see the DHTML it generates. one headsup- your link to the laszlo product page is broken (missing the .org)
sean
June 28th, 2006 at 6:28 am
I’ve been excited about Legals since I heard about it as a possible platform on which to build interactive application UI mockups. (OpenLaszlo 3.x isn’t ideal for this purpose because of limitations in its rendering of raster images, but I imagine that there is no “rendering” in the DHTML runtime and perhaps better support in the Flash 9 one.)
Is this prerelease complete enough to use for this purpose, or should I be waiting a few more months?
June 28th, 2006 at 10:49 am
Hi Dave,
I’d wait a few more months — the high-level UI widgets aren’t yet available in DHTML.
Can you expand on what limitations you see in OL3.x for raster image rendering?
July 6th, 2006 at 9:58 pm
Today I revisited ZK … “AJAX without Javascript” (http://zk1.sourceforge.net/) … I can’t help thinking there’s an overlap in here that could be explored productively.
August 24th, 2006 at 7:25 am
jgrandy,
Sorry to take so long to get back to you. OL3.x’s rendering of PNGs and other raster images is, for lack of a better term, less precise than Flex’s. If you display the same image using OpenLaszlo, Flex, and directly in the browser you’ll see that Flex’s version is very close (though not necessarily identical, I think) to the original, while OpenLaszlo’s is a bit further off.
Particularly for mockup purposes, there are also some issues around fonts: at least for a Mac user, the process of embedding any available font in a Flex app is relatively straightforward if you have Flash Pro. Doing it in OpenLaszlo is more complex and not something I’ve managed to do yet except with an existing ttf file.
I’ll also be excited to be able to take advantage of the Flash 8+ filters like Drop Shadow from OL.
August 24th, 2006 at 12:24 pm
Dave,
You are probably right that our font embedding story is a bit more complex than that available through Adobe’s Flash IDE. But I’m skeptical about the claim that image rendering is inferior, since we just pass raster image data directly to the Flash runtime. Of course, it’s possible there’s still a difference — perhaps we don’t turn on a feature on the Flash8 runtime that the Flash IDE does — but if so we’d love to see a screenshot and sample code so that we can narrow down the problem. (Please contact me directly, jgrandy at openlaszlo dot org, if you can provide more information.)
As for drop shadows and so on, I believe there are OpenLaszlo developers who have used motion blur and other Flash 8 effects within OpenLaszlo apps, so I know it is possible. We haven’t integrated effects into public OL APIs, though, so doing so requires dropping into ActionScript (not a big deal, but not well documented either). But we’re open source, and would welcome anyone who would like to help make this feature happen sooner rather than later.
Thanks again.
August 29th, 2006 at 3:12 pm
I’ll put together an example and contact you directly regarding the image rendering. As to ActionScript, I’d love to see someone write a quick primer on using ActionScript from within OL - I’ve known it was possible for a while but how the AS relates to the LZX and JavaScript is unclear, and certainly it can be useful from time to time.
August 29th, 2006 at 5:10 pm
Hi Dave,
We just this week discovered an anomaly, where the Flash Player will default to lower-quality rendering in certain situations. This condition is triggered in OpenLaszlo if you include a splash screen in your application. We’ll be blogging or writing about this soon, but in the mean time you can try the following workaround to see if it makes a difference. Simply add the following code to your application, either within a canvas or a library tag.
_root._quality = “BEST”;
August 30th, 2006 at 12:04 pm
Sorry, the tags got swallowed there. In English, you want a script block (e.g. script XML element) containing the code in my comment above. So, taking a guess at how Wordpress handles formatting:
<script>
_root._quality = “Best”;
</script>