Monthly Archives: December 2006

XML(e4x) vs AMF

I am having this inner dilemma about AMF vs XML. For a long time (5 years), I have preferred using AMF over XML. It results in lower over-the-wire bandwidth, faster data serialization/parsing, and you get real class instances in AMF3 when using the full spec (See: Flex Data Services and ColdFusion). Then E4X was added into Flash Player 9 and now I am gradually leaning towards XML for several key use cases:

(New to Flex? Some simple facts first:
1. Flash Player has an XML Parser in it.
2. Flash Player can load XML directly over HTTP/HTTPS.
3. Nothing special is required server side.
4. The XML class implements the E4X (ECMAScript for XML) syntax. Think… readable and writable XPath yet much simpler and tons more fun.

Integration with REST

REST API’s are blooming everywhere and SOAP seems to be fading rapidly as a client integration format. REST is easy, readable, easy to understand, and best of all it is port 80 friendly.

E4X makes client side data easy to query. It is one thing to get an object, it is another to get an object and easily query the data interactively.

Here are a few:

In the loaded XML object named myE4XObj:

Give me elements named ‘student’ off the root?

Give me ‘student’ nodes anywhere that have a ‘name’ attribute?

Give me ‘student’ nodes anywhere that a 3.0 or higher grade point average?
myE4XObj..student(@average >= 3)

Now for pure remoting, well that is an AMF thing, for loading models or leaving the result client side queryable, XML with E4X takes the cake. I should note that you can pass XML objects within AMF3 so they remain queryable client side as well, shoot with AMF3 you can pass binary images and SWF files around too.

The problem with AMF is that the secret sauce and recipe are bottled up at Adobe. Although there are many AMF clones out there, they vary wildly in support for the deeper object types in AMF3 binary. They all sort of taste like New Coke or Generic Cola, it tastes similar but something is missing, it is just not the real thing.

What is interesting to me is the fact that AMF is easily 10X faster and lighter than SOAP Web Services for server to server and server to client operations. We have all this server iron out there wasting bandwidth and CPU time parsing XML when they could natively serialize objects with less memory and less bandwidth. AMF3 is a perfect spec for it but we need clients and servers for AMF in many languages first. Currently the AMF format is a transmitter/receiver that can only talk to Flash Player and that needs to change.

I am not sure what 2007 will hold but know that I am lobbying for an open AMF spec in 2007 with server and client implementations for Java/C/CSharp. We need to open up AMF and let it breath. It is really great technology that would enable a wide array of companies leverage efficient data transfer and enjoy native Flash Player data exchange.

2007 is going to be a great year for Flex/Flash/Flash Player/Apollo.

Happy New Year!


Why is IFBIN 2.0 using Apollo?

Patrick Mineault asked why I was writing IFBIN in Apollo and not as a website. There are many reasons but my employer is NOT one of them. Truth be told the original IFBIN plan was to ship on Central 1.5 but given its “developer release” status, things didn’t happen there. Lets dive into the issue:

1. Installed vs URL – There is a lot of value in being installed on the desktop. URLS are hard to remember for regular folks (even advanced folks). Plus with over 200 bookmarks, I struggle to locate a site I found before. Being an icon on the desktop is more valuable than being a website. Many key services will move towards Apollo to enjoy this exclusivity. Plus as Apollo has a browser you can control the experience, yet integrate easily with all things web.

2. Browser is a tiny sandbox – The web browser is a very restrictive sandbox. Why cater to incompatible browser quirks, when your app can become the browser? Apollo lets you control the entire user experience and deliver functionality that websites cannot.

2. FileIO – IFBIN 1.0 made installing secure file systems as easy as 1 click cross platform. If we used a browser, here are the features that would go away:

a. 1-Click – Make installing files easy, do not make me think! I want IFBIN to work for everyone, not a limited market who knows SVN/CVS/ZIP.

b. File Verification – IFBIN can verify if every byte in a file is authentic and genuine. If the file contents have been tampered with, the file will not install. This protects end users and is especially valuable when end users are uploading content into IFBIN.

c. IFBIN Secret Feature #1 – There is a killer feature that can only be delivered leveraging FileIO in Apollo. It makes the web more readable and writable.🙂

3. Scalability – With UI and logic moving into Apollo on the client side, the server side gets simpler and more scalable. Having to send the presentation layer over and over and over and over is silly. It is a waste of bandwidth and server resources that are better handled within the client. I am concerned about scalability with IFBIN server-side and leveraging an intelligent client makes things much simpler, more scalable, and more configurable.

Take the file upload functionality: The user selects a directory to upload, enters meta-data about the file system, and the IFBIN 2.0 Apollo app prepares a binary file to upload that is highly optimized. The file is uploaded to the server where the file is processed into the backend including source search indexing, category publishing, tag processing, and updating a developer profile. The file is then one approval away from being published. Scalability here also applies to my time, I do not have tons of time to manage IFBIN, so the system needs to be 99.99% automated and distributed.

4. Context – IFBIN 2.0 knows what the user has installed, searched, and viewed. The service can notify the user about new versions, similar content, and search for similar files (same author, same class, etc).

5. Partnership – IFBIN is going to work on a partner model to monetize operations. Partnership on the web today is distractive in nature and content sites typically must hand users to another site. As Apollo contains a browser, IFBIN 2.0 can provide a more controlled partnership model in context. Think sponsored bookstore within IFBIN, category sponsorship, and special offers in context with the service.

6. Offline – IFBIN installation files are cached so a user can re-install without a network connection. Typically with examples developer tinker with code to see what will happen. This type of discovery is at the heart of IFBIN in terms of value. If you want to get things back to the starting state, you are 1 click away even if your are on an airplane.

7. 1000’s of HTML pages vs. 1 SWF + API – I think that SWF + API is the right model. It allows me to rapidly change the entire application at once without modifying the server at all. This is 1000 times more scalable than most web production. Also you gain the benefits of having an API for 3rd party integration/syndication without doing anything special. I know many would disagree with me here, but that is my opinion. Leveraging that same model in Apollo is the right call.

8. Persistence – Apollo can persist and cache data on the client side. With client persistence the server-side becomes even simpler. Sessions in Apollo can maintain state far longer than the browser. With IFBIN 2.0, why would you need to login or logout? When client storage becomes rich, many of the key pillars of web technology fall apart. My choice in leveraging TurboGears/CherryPy is the low level control over HTTP, productive development of the XML API, and leveraging ORM mapping in SQLObject. Cookies, Sessions, HTML, Javascript, CSS, AJAX will go unused in IFBIN 2.0 because I am not sending the presentation layer over HTTP and I can persist client data intelligently.

9. Compatibility – Apollo apps run compatibly cross platform. In choosing Apollo, I assure support on Windows, OSX, Linux from the same file! In choosing Apollo I choose the widest possible market for IFBIN. IFBIN 2.0 can provide a dramatically better experience without limiting customer base.

10. Installation – The install process for IFBIN 2.0 and the Apollo Runtime is 1 click. It is so easy, that both my mother and father can do it. I typically rate them a 1 in 10 on a technical scale. Actually installing IFBIN 1.1 today is much harder.

Patrick, I guess in a way I am biased towards this model of development given my experience and job at Adobe. But then again I was biased long before working at Adobe and I know this is the right model to make IFBIN a success. The failure of IFBIN was more personal/business than technical, no need to rehash that uglyness yet again.

Here are some key milestones for IFBIN 1.0:

46,000 installations with a marketing budget of $0.
Average 3,500 unique users in Dec 2006 and rising steadily.
700+ of the best code examples ever assembled for Flash/Flex.
IFBIN royalties paid Darron’s rent by majority 3 months in a row.
I worked with some of the best developers I have ever met.
IFBIN was licensed for use at the MIT Media Lab.
IFBIN acquired 150 customers with whom I am forever in debt. IFBIN 2.0 is dedicated to them. Each customer will be listed in the IFBIN credits.
Zero server downtime, thanks FreeBSD!!
Fun, Simple, and Easy to use.

That is success in my book. It wasn’t financial success but IFBIN was right on many levels. IFBIN 1.0 remains technologically sound, runs cross-platform, and works 100% today. I have a lot of work to do to best IFBIN 1.0 in terms of stability and performance.

Honestly, if I were to build IFBIN from scratch using any technology at my disposal, I would go this exact route. Cross platform distributed applications are the future of the Internet and choosing Apollo gives me a much deeper technology stack than the browser provides. Delivering a dramatically better application experience cross-platform is the bread and butter of Adobe Apollo.

I am sure there are new lessons to learn in the development of IFBIN 2.0. Software development is a journey and the lessons along the way are the fun part.

Lead with Grenades!


IFBIN 2.0 Development

I am working on IFBIN 2.0 all week. It has been 1 year since I worked on IFBIN and it has been far too long. I am going to be blogging my development of IFBIN 2.0 and launching the new version of the service with the Apollo Public Beta in 2007.

IFBIN 2.0 is a client/server application that leverages the internet for data exchange over port 80 HTTP/HTTPS. The desktop IFBIN client allows an end user to find/download/upload software examples from the IFBIN repository. The server side is an API that is accessed by the Apollo client. With the exception of the IFBIN file format, all data is stored and transmitted uses XML. The IFBIN file format contains meta-data about a file system and the data within the file system itself. Having 1:1 files per examples on the server side makes file management much easier, especially given the files named with the SHA1 key of the file data. This allows for some great server automation in dealing with files as file naming can be dynamically applied to the uploaded files.

IFBIN Server Stack:
– THTTPD (static binary data over http)
– TurboGears 1.0 (CherryPy, SQLObject, Kid)
– Python 2.4.4
– FreeBSD 6.1 Minimal/Optimized

IFBIN Client Stack:
– Flex 2.0.1
– MXML & ActionScript 3
– Apollo Runtime

The server will use THTTPD, TurboGears, Python 2.4.4 running on FreeBSD 6.1. The goal is for the server to be very scalable while supporting rapid development. In this case, Python is ideal on FreeBSD 6.1 within a TurboGears instance. The IFBIN 1.0 client and server used Python and leveraging this on the server is ideal.

The existing IFBIN Server is actually 100% static and is generated onPublish via a Python API. Using URLReWriting on Apache the Flex 1.5 UI loads data remotely to present the UI Data. This model worked very well as a full republish took 2sec writing some 1200 files to the file system. The server will have as few dynamic URLs as possible by by majority most content will be statically cached.

The dynamic APIs will be:

– User.Register()
– User.Login()
– User.Reset()
– User.Profile()
– Example.Search()
– Example.Upload()
– Example.Rate()
– And some surprises…🙂

These areas will all be written using TurboGears and Python. I believe that this will allow for very rapid development of the backend for IFBIN 2.0 as the backend is simply an API. Flex will provide the complete UI within the Apollo application.

Building IFBIN last time was a blast and I expect to learn a ton. I have put a lot of thought into IFBIN 2.0 and I look forward to its release in 2007.

More to come!


Surfacing Flex – Part 2

So this morning I arrived to find 2 new FlexApps in my inbox. I do not think anyone at Adobe has seen either one of these apps before. Both are medical imaging applications, one shows images of an MRI and one a thermal imaging of an exam. Here are some images:

Special thanks to:

Wheeler Street Design

for posting images to FlexApps!


Posting Images to FlexApps

1. Capture images of flex application.

2. Email: like so:


TagTV searches images and video at Flickr and YouTube. tags: mashup, flickr, youtube

3. Attach Images (NO ZIP FILES!!!)

4. SEND!

– Post images you have permission to post.
– Right to remove images is reserved.
– No notification of publishing will be provided.
– Image publishing will occur in the order they arrive.



Back in Black – CS3 Icons and Fx center stage!

I really like the new CS3 icons. Looking at the single color wheel it isn’t obvious what is going on, but when you see the icons in the OSX dock and use the apps daily it makes sense. The chips are designed to look like the periodic table of elements.

Here is OSX dock on CS3 (yes I switched last month)!

The CS3 seamless ui makes the icon design and suite very clear. CS3 is going to be a killer release, having used Dw,Fw,Fl,Fx,Ps daily they are a order of magnitude better than prior versions in both design and functionality.

What I think is really cool is that Fx (Flex) is dead center, hmmmmm. Coincidence? Think again!

Look for a Flex release coming very very soon, 2.0.1 simply rocks!



Surfacing Flex

Want to showcase a Flex application and get developer/company credit? I have created a Flickr account to showcase images of Flex applications. Many times Flex apps reside hidden behind the firewall and public viewing of the live app is impossible. Follow the directions below to get your application showcased on FlexApps!


Posting Images to FlexApps

1. Capture images of flex application.

2. Email: like so:


TagTV searches images and video at Flickr and YouTube. tags: mashup, flickr, youtube

3. Attach Images (NO ZIP FILES!!!)

4. SEND!

– Post images you have permission to post.
– Right to remove images is reserved.
– No notification of publishing will be provided.
– Image publishing will occur in the order they arrive.