Monthly Archives: November 2003

Why Central will work…

Initially I wasn’t that hot on the concept of Central as I didn’t fully understand it. Hopefully this will change your mind.

Bauns by Ferry Halim

I found this game online. But I have to say it is one of the most addictive Flash games I have ever played. It rivals Tetris in gameplay, and the visual interactive quality is spectacular. If this content made its way onto Central, I would pay money for it.

I guess the key here is that someone, somewhere, will create a extremely compelling chunk of bits that users will be willing to pay for. When a developer finally gets paid for their work, more amazing content will begin to flow towards Central. This parallels the game platform in market mechanics. Game systems don’t sell themselves, great games sell game systems.

So what if Macromedia gets 20%-25%, they enabled you to get paid in the first place. Don’t think about it like 20% less, but rather 100% more than before Central happened.

Deep thought: Would Atari have ever become popular without Pong?

Happy Thanksgiving! Good Gaming.



Blog Comments & Errors

I found an error in my blog comments and the old system had to go. I just finished installing the new version, hopefully it will allow for better interaction and feedback plus comments are inline. Fire away, I will hear you and as always I do not edit comments (!spam). Cheers, Ted๐Ÿ˜‰

A lesson from the XML Object – Inner References

The XML Object is a collection of objects and properties structured to conform with the Document Object Model. The key is that it is a hierarchy of objects containing internal references.

I often structure objects/classes in this manner as they provide a simple way to nest objects in objects. The problem is managing the nested objects in a relative manner. By default Objects do not understand the hierarchy they are contained within from an internally perspective. Take this object for example:

//Florida feeding hierarchy

alligator = {dog:{ cat{ mouse:{ cheese:{} } } }

The cheese object has no idea that it is within the mouse, same with mouse, cat, and the dog in the alligator. This hierarchy is fundamentally location independent as _parent, ../ references do not exist.

Worse still if I come along and make a direct reference to cheese:

myCheese =

I have no idea that myCheese is within mouse or in a hierarchy at all.

Worse still is that if I am the cheese object, I cannot know the names of my references (with the exception of reference counting). Cheese doesn’t know it is cheese and neither does mouse, cat, dog or alligator. It is sort of like inner amnesia, Who am I?

Not that I am complaining about how this works, objects should be clueless internally. This is a very good thing but it can cause problems if you do not understand how it works. Objects are reference based in the player, eliminate all references and your object is swept up by the garbage collector.

The XML Object provides inner references to eliminate these problems. My hierarchy would look like so if it were an XML Object:

alligator = new XML(”)

The inner hierarchy is composed of individual XMLNode objects mapped into a hierarchy by references. You can then externally or internally walk this hierarchy in a structured way once the XML has been parsed into its object representation.

So how do we fix our hierarchy to be self referencing? Easy lets add some properties.

Child Objects are easy as you can simply reference them by name. Walking down the hierarchy is easy but walking up the hierarchy is typically the problem. There are 2 properties you need to provide:

_parent = A reference to the container object

_name = A property string of the instance name of the object you are within.

Both of these should seem familiar as it fits into the MovieClip hierarchy pattern. I use these names so that objects and MovieClips subtly become in sync during development. It is a bit confusing as first, but it elevates many of the problems in self-referencing objects. The fact that we must treat these two dataTypes unequally is a major problem in the player. (Rant, Rant!)

One issue here is that N references can point to an Object but you should only want the hierarchy walked up in one direction. If there were 2 references to an Object, from within the object how would you know which way to go, confusing. Or how would you know there was a reference at all? The Player knows, but as of yet we cannot know programatically (Hint, Hint, Nudge, Nudge!).

alligator = {_name:’alligator’} = {_parent:alligator,_name:’dog’} = {,_name:’cat’ } = { , _name:’mouse ‘ } = { , _name:’cheese’ }

The tree ends up looking like a link list except cast into an object hierarchy. For example assume I am scoped within cheese all of these tests are now true:

this._name == ‘cheese’

this._parent._name == ‘mouse’

this._parent._parent._name == ‘cat’

this._parent._parent._parent._name == ‘dog’

this._parent._parent._parent._parent._name == ‘alligator’

Ideally this hierarchy would be created via a class so that the properties _name and _parent would be added without getting procedural. Mouse might have a method eat(target) allowing it to consume the cheese object and configure the references correctly. Also when you destroy the objects, you should delete the inner references so the object will be garbage collected, inner references will keep an object in memory. It also might be nice if Macromedia would shine some light on this subject for all of us.(Hint, Hint!)



FLAVOR – Roundtrip encoder/decoder for bitstream data (SWF)

One of the most difficult tasks in working with Flash is writing swf files. I found this tool that uses a class or XML schema to produce a roundtrip encoder/decoder for any bitstream format including swf!๐Ÿ˜‰.

From some initial testing you can easily encode XML into SWF. Even better is the fact that the same code will parse the SWF format back into XML perfectly. If you develop using this toolkit, encoding and decoding are developed at the exact same time reducing errors. The code generator outputs C++ or Java code or uses a standardized executable for XML processing. The toolkit has been successfully used to encode and decode MPEG-4 and many other bitstream formats.

I took a copy of the F7 File Format and made a schema that defines the SWF header blocks. It works perfectly round trip. The only thing needed now is a full blown XML schema for the entire Flash File Format. One day at a time!๐Ÿ˜‰

Best of all it is open source and is a very hardened piece of software.



Retrospective MAX – The Big Review (Corrections)

David Mendels (MX Products – Macromedia) emailed me some corrections to my blog entry. David’s corrections are posted here in an unedited format to allow readers to get a full perspective.


a) There is no reason Flex apps should be 1 or more megabytes. We are targeting internet, not just intranet. The Whitman Hart Executive Information System application I showed in the keynote was something like 200K.

b) I am not aware of any former IBM Lotus engineers on the project—components or Flex. Nothing against ’em, but I can’t imagine where this rumor comes from. We do have folks from the Flash team, the Dreamweaver team, the JRUN team, the ColdFusion team, and some very strong folks who joined more recently from a whole bunch of different backgrounds. Again, I am not sure if it would mean anything anyway–they had some great engineers on that team.

c) The Flash team did not rebuild most of the Flash Authoring UI using the JSAPI. Not sure where this rumor might come from.

d) One can argue that Flex imposed requirements on the 2004 components or the other way around. But the design goal was a common component set so that teams could work together, and Flash Pro could be used to create custom SWCs that Flex programmers could use in their applications. I still think this is the right design goal. Developers are not going to choose one way and one way only to build their Flash RIAs, rather, many will use a combination of Flash and Flex and I think if we can keep the components common that is in everyone’s interest.

e) I am not sure where you got the pricing speculation. This is also rumor. Yes, we have indicated that it will be priced like other enterprise server software, and yes, this will price it out of some projects without a doubt; but we are not done on the pricing and the numbers you report are far enough off what we have been discussing as to potentially be misleading. You are right to caution folks on this front, and I would as well; but until we publish (and first, finalize) our plans, it may be premature to be scared off.

Anyway, you have a lot of good points and food for thought. As much as I am excited about what we are doing at Macromedia, I agree that the community will drive more innovation than we ever could.





Thanks David for clarifying the issues more completely. I do appreciate the fact that Macromedia listens to end user opinion and the fact that you addressed your concerns directly is great for everyone. I certainly do not want to be seen as publishing incorrect information hence I posted your corrections unedited. As far as the corrections, I am happy to wait and see how these issues play out long term as I still feel my sources of information were fairly solid and honest else I wouldn’t have published the information in the first place.

Depending on your perspective you can take a collection of individual facts in many different directions, only with time can we see which perspectives were correct or distorted. David, thanks for contributing your perspective and correcting some obvious misunderstandings and rumors.



Sugar-Coating and Recognized Individuals

I received a few emails about Retrospective MAX – The Big Review as I spoke openly about several aspects of Macromedia and MAX. I am not one to hold back or sugar-coat my opinion when it comes to my profession or the tools I use with regularity.

I am paid professionally to provide my opinion in regard to consulting projects. I take that role very seriously as I am really asking others to spend money based on my opinion. My consulting clients deserve an unbiased perspective and one in which I have truly explored alternatives that might position a project for success. I would hope that if you were a consulting client of PowerSDK Software Corp., you would appreciate my candor and my honest unbiased perspective.

We are at the very beginning of the rich media revolution and if the tools and techniques are going to improve dramatically sugar-coating your opinion just holds things back. Tool developers like Macromedia need your raw opinion in order to improve their products. I personally spent a good percentage of time at MAX listening and learning from developers in regard to improving PowerSDK products, FLOW and SYNC. Talking to customers allowed me to understand their perspective and to fine tune development to meet their needs.

The individuals named in the Blog entry were recognized for their personal work. In no way and at no time did any of the listed individuals leak information to me. The controversial information provided was gathered from many sources across the course of the conference and specifically not from the individuals listed. To hold any of these individuals accountable would be a mistake on the part of management at Macromedia. Mike Chambers and Gilles Drieu are exceptional individuals making a profound contribution to Flash and were listed as such. If anyone at Macromedia has an issue with my comments or the information provided I welcome them to contact me directly to address their concerns.



Retrospective MAX – The Big Review

Looking back at the past week, it is very apparent that some big changes are in store for Flash although it was strikingly obvious to me that innovation will come from the community and not from Macromedia.


MAX was a great conference, not due to the sessions, but from the great developers in attendance. I learned much more from the community, the core Flash development team, and the late night coding sessions than from any part of the conference. I had the pleasure to meet many developers and discussed development problems and related issues with them. I look forward to keeping in contact with everyone I met at the show, I had a great time. Thanks!๐Ÿ˜‰

One of the hidden trends at the show was that allot of developers are struggling to adopt Flash for business development, RIAs are not easy to build! In speaking with many developers after my sessions and in the development forums, Flash is very difficult to understand if you have not evolved with the medium. Although we have shiny new features in AS2 , new components, standards support, and a better IDE, we are still bound by a lack of understanding of what happens at runtime. Behind the all these features are a set of simple datatypes and structures in the player that have been present since the pre Macromedia days of FutureSplash Animator. Choosing to ignore these basic rules and you will struggle with Flash, it is just that simple. Here is an example I used in my session on “Component-Oriented Development with Flash”:

//Depth precedence

_level0.createEmptyMovieClip(‘ted’, 40)

_level0.createEmptyMovieClip(‘ted’, 20)

trace(_level0.ted + ‘ ‘ + _level0.ted.getDepth())

//Data precedence over MovieClips

_level0.createEmptyMovieClip(‘ted’, 0)

_leve0.ted = 101


The key here is that if you fail to understand the differences in MovieClips and Object Data at runtime, you will fail to build effective component applications as a simple error will render your application useless. These errors are due to path processing at runtime between the object data and movieclipDatatypes and all fail silently in the new MX 2004 IDE. These issues need to be addressed so that new developers will not be hindered by these low level problems. I also think that Macromedia and the community should more openly disclose the details of the interpreter at runtime. It is one thing to make the swf format open, but quite another to explain bytecode effects at runtime (not that everyone wants to know but some of us do!). Even now, this is a dark art and limited to a handful of developers inside MM and a few in the community. Only when you understand an actions effect can you effectively solve a larger problem. Give the community some insight and we many find the state of Flash is moved forward dramatically.

One solution to this problem is to add a new development paradigm hence FLEX (Royale). It seemed like lots of developers are pinning their hopes to this “newest of new” server but I remain firmly skeptical. I went to all of the FLEX sessions, asked some hard questions, and saw some subtle problems that are a bit scary from my perspective.


1. SWF output files are huge (1MB+). One of the demos at the show was 2+MB! Think Intranet not Internet delivery!

2. FLEX imposed changes on V2 components. We received FAT components due to FLEX compatibility(SWC).

3. Components are bound into the one big SWF. This is the same mistake that LASZO made and support for progressive loading will not be included until a version 2 release. There are ways to solve this problem today that are as of yet unexplored.

4. Expensive, $5,000 to $10,000 per CPU! WOW, I thought generator was expensive.

5. F7 support only.

6. Most of FLEX 1 can be done client side in the player today. This killed generator as a product.

7. Lack of support for remoting.

In the meantime, I am looking elsewhere. Turbine 7 looks promising as does Kinetic Fusion’s latest release. If you walked away from MAX thinking FLEX will solve all your problems, be careful. Version 1 releases have a tendency to be a very bumpy ride and will not always fulfill your expectations. I am not sure I would recommend it as a consulting solution but that is just my opinion on the matter. Seeing as things will be optimized prior to release, conditions may dramatically improve but I am not holding my breath. I am sure rich media will penetrate the enterprise, but its development may not come through FLEX.

I had the pleasure to meet several members of the core Flash development team. I sat down with Gilles Drieu and talked about a myriad of issues in Flash MX 2004. Based on our conversations, I would expect to see some great things come from Gilles area in regard to designers/animators. Your in great hands as Gilles is an absolute professional and dedicated to making the graphical aspects of Flash a top priority in the next release. We discussed project workflow and some of the issues related to team development especially integrating design into development (skinning, version control, External Libraries). Thanks Gilles!;)

I talked to Mike Chambers about Central and he fundamentally changed my opinion about the product. Central’s value is subtle and is very easy to miss. Unlike internet applications, parts of Central apps run all the time vs running only when I visit the web page. With all other internet applications, I must do something to use them (Remember the service, Enter URL, Use application), with Central the information comes to me with no effort. Mike explained that after a long period of use, Central provides much greater value in that agents provide updated information and alert you to changes in data. Considering that I missed the big reason Central was important, I am sure there are many still pondering its development. Central is important as it shifts execution of short term (browser) applications to a long term process on your local machine combined with seamless installation and updating. You are now talking to the converted, Central rocks! Also Kudos to the Central team for the great API poster and the naming changes in Central components and SDK. Mike your efforts have made the SDK easier to understand and easier to use. Sorry I was such a nagging A-Hole about Central, I didn’t understand it, and I stand humbly corrected. Thanks Mike!๐Ÿ˜‰

In speaking with others, I gathered that the MX2004 Flash release was internally problematic at Macromedia. A couple of developments made the release what it was. Here are a few of the issues:

1. MX Studio common release date (Dreamweaver, Flash/Flash Pro, Freehand, Etc). Flash was a very ambitious release adding a myriad of features, yet every studio release product was required to share a common deadline. Personally, I would have rather seen MX2004 launch at at MAX, than to have received an unpolished product. Uncouple the Studio product and release Studio MX like a mini-DEVNET (online), the products will be of a much higher quality and developers will upgrade as their key application is released. Ideally marketing and development both win as software quality improves!

2. FLEX imposed late design changes on the component architecture for MX 2004 as the products were required to share SWC components. Also the V2 component architecture added string support to allow FLEX to do its job. Instead of receiving an improved model, we received a model intended for use in FLEX and not optimized for component development with Flash MX 2004. The components also had to be usable for V6 of the player making the common design even more difficult and more convoluted.

3. The team had to rebuild most of the IDE functionality in XMLUI on the JSAPI foundation. Not an easy task, especially with the high expectations of the tools given prior Flash releases. This dramatically increased the work the team needed to accomplish as every panel, control, GUI element needed to be rebuilt in the Dreamweaver API model. This was a massive change in the IDE and compounded all aspects of the release.

4. Core team members departed the company and key developers were shuffled around mid-project.

Talk about a tough set of requirements. Given the circumstances, the Flash team did an amazing job. I question management’s and marketing’s judgment on pushing the team this hard and imposing dramatic changes (FLEX) late in the development cycle. I would much rather get a solid release than a pile of new features, quality not quantity. Hopefully management and marketing will listen to this request as they screwed up the Flash MX 2004 release, and the development team saved the release through hard work. The dev team deserves allot of credit in doing their best under difficult development circumstances and for providing a solid update to the release. Thanks!๐Ÿ˜‰

Another interesting presence at MAX was that of IBM. At the keynote, sneaks, and at other parts of the show, IBM was very present, listening, watching, and waiting. Actually I spoke with several IBM engineers at the show after my session, it was most enlightening. As MAX rumor has it, MACR has been hiring IBM Lotus Notes engineers and some of them are responsible for architecting V2 components and parts of FLEX. Even more amazing is that IBM is adding development support into Eclipse for FLEX. It is not very often that a 152 Billion dollar company caters down to a 1.3 Billion dollar company without an agenda. This is a clear sign of things to come, Macromedia has become an acquisition target as the leader in rich media application development. IBM and Microsoft have obviously taken notice. When enterprise software purchasing takes hold again, we may see some consolidation in the industry that profoundly affects Macromedia. From my perspective, the writing was on the wall at the MAX conference, it is just that simple. Although, after seeing the IBM engineer at the sneaks, merging corporate culture at IBM and Macromedia should be very interesting to watch.

Not that any of these items change the Flash opportunity, but we will see some amazing changes in the coming year. Although I expect the community will provide an order of magnitude more innovation than what I saw at MAX. Some things never change.๐Ÿ˜‰